Getting back into translating the Win32 headers - anyone?

[Stewart Gordon]

Chris Miller wrote:
> On Sat, 02 Dec 2006 09:54:14 -0500, Stewart Gordon <smjg_1998 at yahoo.com> 
> wrote:
<snip>
>> 4. There seem to be a few ways of doing the variable-length structs 
>> in use.
<snip>
>>          MIB_IPADDRROW[1] _table;
>>
>>          MIB_IPADDRROW* table() { return _table.ptr; }
<snip>
>>          MIB_IPADDRROW _table;
>>
>>          MIB_IPADDRROW* table() { return &_table; }
<snip>
>>          MIB_IPADDRROW _table;
>>
>>          MIB_IPADDRROW[] table() { return (&_table)[0..dwNumEntries]; }
>>      }
>>
>> Which should we settle with? I personally think the proposed idea
>> is a good one. Just as the C headers make use of C's lack of ABC,
>> so the D translation would make use of D's ABC. Look also at the
>> idea for custom allocators for these things on the discussion page
>> of the wiki.
> 
> I think I prefer the first one, as it most resembles what MS did. The 
> last one is probably too D-like for a C interface, especially 
> considering the C version of table would decay into a pointer, and 
> yours would be a D slice.

I'm not sure what you mean by this.  We already make a few little bits 
make more sense for D, such as translating COM interfaces.  In C, table 
is a one-element array, which is neither a pointer nor a D slice.  D 
array slices decay into pointers too; even if they didn't, the 
difference between writing table and writing table.ptr is trivial IMO.

>> 5. I've noticed that bit field setters have variously, depending on who
>> coded them up, been declared to return void or to return the value
>> passed in.  Is there any reason to have them returning void?  We ought
>> to make these consistent.
> 
> Unsure. Perhaps D's properties should automatically call the getter if 
> the setter is used as an rvalue and it returns void.

I've proposed this before.

http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=10199

I can't believe it's taken so long for anybody to second this idea!

> Also consider foo.prop++; it should probably call the getter, apply 
> ++ and call the setter with the new value. This automatic calling of 
> getter/setter as appropriate seems more simplistic and pure, and 
> should probably be addressed before 1.0 so that properties aren't 
> crippled in the spec.

I agree.

>> 6. In many modules, class IDs defined externally in a library are being
>> declared without the const attribute.  Is there some reason for this?
>> They're constants, so surely they should be declared as such.
> 
> Is const stuff even added to object files? This might be why..

We don't need to add them to any object files.  They're already in the 
.lib files, where they need to be.

Stewart.