"Rob Grainger" <nospam@nospam.com> wrote in message news:d03bmk$1khd$1@digitaldaemon.com...
> Regan,
>
> As a brief postscript, I do like the increased type safety typedef
> gives - its
> always annoyed me in C++ not being able to overload on different
> typedef's.

You can, with True Typedefs. (Chapter 14 of Imperfect C++). <g>


> As long as there no interactions at ABI level to prevent this, making
> alias
> a better choice.

Walter's said many times in the last few years that this approach is unmanageable, yet it's brought me nothing but goodness. Go figure!

Regan Heath wrote:

>> Just letting you know that in object.d we already have ...
> 
>> version (AMD64)
>> {
>>     alias ulong size_t;
>>     alias long ptrdiff_t;
>> }
>> else version (X86)
>> {
>>     alias uint size_t;
>>     alias int ptrdiff_t;
>> }
>
> Thanks Derek, I had forgotten where this was.
> 

Side Note:
In the portable version of Phobos, this passage reads:

version (GNU)
{
    version (GNU_BitsPerPointer32)
    {
        alias uint size_t;
        alias int ptrdiff_t;
    }
    else version (GNU_BitsPerPointer64)
    {
        alias ulong size_t;
        alias long ptrdiff_t;
    }
    else
    {
        static assert(0);
    }
}
else version (AMD64)
{
    alias ulong size_t;
    alias long ptrdiff_t;
}
else version (X86)
{
    alias uint size_t;
    alias int ptrdiff_t;
}
else
{
    static assert(0);
}

Where GNU_BitsPerPointer is set automagically by GDC:

> #if UNITS_PER_WORD == 4
>     VersionCondition::addPredefinedGlobalIdent("GNU_BitsPerWord32");
> #elif UNITS_PER_WORD == 8
>     VersionCondition::addPredefinedGlobalIdent("GNU_BitsPerWord64");
> #endif
> #if POINTER_SIZE == 32
>     VersionCondition::addPredefinedGlobalIdent("GNU_BitsPerPointer32");
> #elif POINTER_SIZE == 64
>     VersionCondition::addPredefinedGlobalIdent("GNU_BitsPerPointer64");
> #endif

And those C macros are in turn set by GCC's configure.

--anders


PS.
You still need Wine for the Win32 API's, though... :-)
http://www.winehq.com/

Rob Grainger wrote:

>>>Which is more readable/understandable?
>>>
>>>    extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM 
>>>wParam, LPARAM lParam)
>>>
>>>or
>>>
>>>    typedef void* Handle = (void*)0; // a typedef, but a useful one
>>>    extern (Windows) int windowCallback(Handle handle, uint message, uint 
>>>param1, int param2)
>>
>>I think we both agree on this.

Hope you mean the first version, because even I recognize that one...
And when reading Win32 API documentation, it would be the one I'd find.


Here is one article, which you might find interesting:
(it's about interfacing OS APIs with Java, but anyway)

http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html

Maintaining the one-to-one mapping is important, and
I would say this also includes the types being used ?


> Me too, but think it would slow down a lot of Windows developers (myself included).
> 
> Hope these comments are useful - at least worth a moments consideration.

Many other libraries also add their own types, which are D aliases.
Some examples are: OpenGL, libSDL, and Mac OS X's Carbon API...

It's easier to add a dozen aliases, than to change all the functions...

EXAMPLES
========

OpenGL: (gl.gl)
> alias ubyte GLboolean;
> alias byte GLbyte;
> alias short GLshort;
> alias int GLint;
> alias int GLsizei;
> alias ubyte GLubyte;
> alias ushort GLushort;
> alias uint GLuint;

libSDL: (sdl.types)
> enum SDL_bool : int {
>         SDL_FALSE = 0,
>         SDL_TRUE  = 1
> }
> alias ubyte     Uint8;
> alias byte      Sint8;
> alias ushort    Uint16;
> alias short     Sint16;
> alias uint      Uint32;
> alias int       Sint32;
> alias ulong     Uint64;
> alias long      Sint64;

Carbon: (macosx.carbon)
> alias ubyte Boolean;
> alias  ubyte UInt8;
> alias   byte SInt8;
> alias ushort UInt16;
> alias  short SInt16;
> alias   uint UInt32;
> alias    int SInt32;
> alias  ulong UInt64;
> alias   long SInt64;

Even for "pure" D code, some aliases are good. Like bool and str :-)

But interfacing with C libraries is different, and has way more legacy.

--anders

Matthew wrote:

>>As a brief postscript, I do like the increased type safety typedef gives - its
>>always annoyed me in C++ not being able to overload on different typedef's.
> 
> You can, with True Typedefs. (Chapter 14 of Imperfect C++). <g>

That does it! ;-)

Now it seems like there is *no* alternative but to fork out
the $60 that the local bookstore wants for it, or this will
just never stop... (Might as well get DDJ for $20, as well,
so that I can read Walter's and Matthew's articles in it ?)

http://isbn.nu/0321228774

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:d040oi$2a02$1@digitaldaemon.com...
> Rob Grainger wrote:
>
>>>>Which is more readable/understandable?
>>>>
>>>>    extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM
>>>> wParam, LPARAM lParam)
>>>>
>>>>or
>>>>
>>>>    typedef void* Handle = (void*)0; // a typedef, but a useful one
>>>>    extern (Windows) int windowCallback(Handle handle, uint message,
>>>> uint param1, int param2)
>>>
>>>I think we both agree on this.
>
> Hope you mean the first version, because even I recognize that one... And when reading Win32 API documentation, it would be the one I'd find.

You recognise it because you're familiar with reading the C API, as am I. But we can't assume all users of our libraries will share that experience. And they won't be looking up things on MSDN - they'll (hopefully) be reading the library's documentation. I think it's more important to make life easier for them than for ourselves. It might also turn off people coming from Java or C#, where aliases for basic types don't exist.

An alternative is to put the SDK version of a declaration in the library's documentation, or in comments in your code, thereby keeping both camps happy.

>
>
> Here is one article, which you might find interesting: (it's about interfacing OS APIs with Java, but anyway)
>
> http://www.eclipse.org/articles/Article-SWT-Design-1/SWT-Design-1.html
>
> Maintaining the one-to-one mapping is important, and
> I would say this also includes the types being used ?
>
>
>> Me too, but think it would slow down a lot of Windows developers (myself included).
>>
>> Hope these comments are useful - at least worth a moments consideration.
>
> Many other libraries also add their own types, which are D aliases. Some examples are: OpenGL, libSDL, and Mac OS X's Carbon API...
>
> It's easier to add a dozen aliases, than to change all the functions...
>
> EXAMPLES
> ========
>
> OpenGL: (gl.gl)
>> alias ubyte GLboolean;
>> alias byte GLbyte;
>> alias short GLshort;
>> alias int GLint;
>> alias int GLsizei;
>> alias ubyte GLubyte;
>> alias ushort GLushort;
>> alias uint GLuint;
>
> libSDL: (sdl.types)
>> enum SDL_bool : int {
>>         SDL_FALSE = 0,
>>         SDL_TRUE  = 1
>> }
>> alias ubyte     Uint8;
>> alias byte      Sint8;
>> alias ushort    Uint16;
>> alias short     Sint16;
>> alias uint      Uint32;
>> alias int       Sint32;
>> alias ulong     Uint64;
>> alias long      Sint64;
>
> Carbon: (macosx.carbon)
>> alias ubyte Boolean;
>> alias  ubyte UInt8;
>> alias   byte SInt8;
>> alias ushort UInt16;
>> alias  short SInt16;
>> alias   uint UInt32;
>> alias    int SInt32;
>> alias  ulong UInt64;
>> alias   long SInt64;
>
> Even for "pure" D code, some aliases are good. Like bool and str :-)
>
> But interfacing with C libraries is different, and has way more legacy.
>
> --anders

John C wrote:

>>Hope you mean the first version, because even I recognize that one...
>>And when reading Win32 API documentation, it would be the one I'd find.
> 
> You recognise it because you're familiar with reading the C API, as am I. 

And I suppose all the rest trying to use the API in question, as well ?
Like in all sample code and in all printed books that can be found...

> But we can't assume all users of our libraries will share that experience. And they won't be looking up things on MSDN - they'll (hopefully) be reading the library's documentation.

Porting the C/C++ headers into a D import module is enough work
*without* having to translate all types and documentation, IMHO.

> I think it's more important to make life easier for them than for ourselves. It might also turn off people coming from Java or C#, where aliases for basic types don't exist.

That's too bad for them, isn't it... ? It's a good thing D has it.

> An alternative is to put the SDK version of a declaration in the library's documentation, or in comments in your code, thereby keeping both camps happy.

Duplicating each function, as if people read documentation ? :-)
As long as it can be fully automated, I guess that *could* work...


My thoughts:
The more copy-and-paste the H2D process of translating is, the better.
As it is now, it's pretty straightforward - with a few minor caveats.

And if it's easy to use C libraries, it makes D all that more useful.
(even if those libs are not using Exceptions or GC or OOP or anything)

Like Walter says: (in http://www.digitalmars.com/d/phobos.html)
> D provides direct access to C runtime library functions and operating  system
> API functions. Pointless D wrappers around those functions just adds
> blather, bloat, baggage and bugs. 

With the aliases, I've found porting at least three major APIs and
a few smaller ones to be a doable task (at least with some Perl help)


That doesn't stop the D programs and libraries from being high-level,
of course. Here I was just talking about the actual low-level C APIs.

--anders

Anders F Björklund wrote:
> Matthew wrote:
> 
>>> As a brief postscript, I do like the increased type safety typedef gives - its
>>> always annoyed me in C++ not being able to overload on different typedef's.
>>
>>
>> You can, with True Typedefs. (Chapter 14 of Imperfect C++). <g>
> 
> 
> That does it! ;-)
> 
> Now it seems like there is *no* alternative but to fork out
> the $60 that the local bookstore wants for it, or this will
> just never stop... (Might as well get DDJ for $20, as well,
> so that I can read Walter's and Matthew's articles in it ?)
> 
> http://isbn.nu/0321228774

If you only had money for a single magazine subscription, then I'd say DDJ is it!

Georg Wrede wrote:

> If you only had money for a single magazine subscription, then I'd say DDJ is it!

I got it... So far DDJ is $10 per article read, but that's about
the usual rate from when I used to buy it on the magazine stand. :-)

Shipping paper to us europeans just isn't very cost-effective...
I actually got all of DDJ, Software Development mag and CUJ now!


"The D Programming Language"
http://www.ddj.com/documents/ddj0202c/

"printf Revisited"
http://www.ddj.com/documents/ddj0501e/


So now I know some more about Walter's decisions behind D and writef.
Too bad I can't share or discuss with the rest of you, due to ©...

I guess the upcoming book will have a similar problem, unless we all
sign up for it in advance and get a private chatroom or something ?

--anders

John C wrote:
> Which is more readable/understandable?
> 
>     extern (Windows) LRESULT windowCallback(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
> 
> or
> 
>     typedef void* Handle = (void*)0; // a typedef, but a useful one
>     extern (Windows) int windowCallback(Handle handle, uint message, uint param1, int param2)

It is extremely important to _never_ try to rename things like LRESULT, HWND, UINT, WPARAM, LPARAM  to anything else. Most especially HWND, LPARAM and WPARAM.

Were these renamed, then their users could never ask any Windows savvy programmers for advice. These words are _cornerstone_ words in Windows programming.

They also bring a certain level of independence of architecture. Ideally one's own programs should work on any hardware platform that Windows supports now or in the future, and only by using these words as such is there hope for it.

I'm not too happy either with the first example above, and I admit that the second is more readable. But this is only at the beginning. Using the second version will keep people from getting familiar with the standard way of Windows programming, and thus just move the same barrier down the road, where it's waiting for you with a vengeance. :-)

So the suggestion is as useful as converting all keywords of the D language to Finnish, for Finnish programmers.

"Anders F Björklund" <afb@algonet.se> wrote in message news:d0419i$2aeg$1@digitaldaemon.com...
> Matthew wrote:
>
>>>As a brief postscript, I do like the increased type safety typedef
>>>gives - its
>>>always annoyed me in C++ not being able to overload on different
>>>typedef's.
>>
>> You can, with True Typedefs. (Chapter 14 of Imperfect C++). <g>
>
> That does it! ;-)
>
> Now it seems like there is *no* alternative but to fork out the $60 that the local bookstore wants for it, or this will just never stop... (Might as well get DDJ for $20, as well, so that I can read Walter's and Matthew's articles in it ?)
>
> http://isbn.nu/0321228774

What an excellent idea. May I recommend that everyone goes out and buy it? <CG>