www.digitalmars.com         C & C++   DMDScript  

D - alias vs typedef

reply "Scott Egan" <scotte tpg.com.aux> writes:
I noticed that in std.c.windows.windows the types are all defined as
aliases.  Would it be better from a type safety and potential overloading
point-of-view to use typedefs?
Apr 19 2004
next sibling parent reply Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
"Scott Egan" <scotte tpg.com.aux> wrote:

 I noticed that in std.c.windows.windows the types are all defined as
 aliases.  Would it be better from a type safety and potential overloading
 point-of-view to use typedefs?

I think that each case would have to be looked at, but in general I agree - - it's always been a problem with the Windows API that so many things are C typedef's and can't be distinguished at all with overloading. -- dave
Apr 19 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
In article <Xns94D0503668634dsiebersbc 63.105.9.61>, Dave Sieber says...
"Scott Egan" <scotte tpg.com.aux> wrote:

 I noticed that in std.c.windows.windows the types are all defined as
 aliases.  Would it be better from a type safety and potential overloading
 point-of-view to use typedefs?

I think that each case would have to be looked at, but in general I agree - - it's always been a problem with the Windows API that so many things are C typedef's and can't be distinguished at all with overloading. -- dave

This has been brought up before. Here's part of Walter's perspective: "One of my early thoughts was also to clean up the win32 type system. Unfortunately, most code plays fast and loose with using C typedefs mixed in with the underlying types. Microsoft's own sample code is woefully inconsistent about it. It's so much easier to just use alias for them and not worry about it. Save the clean designs for doing something new, not legacy API's." (D/15278) I agree with Walter. It seems to me that using typedefs in the windows headers would require a lot of unrewarded effort. (But you're free to disagree.) JC
Apr 19 2004
next sibling parent Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
J C Calvarese <jcc7 cox.net> wrote:

 I agree with Walter. It seems to me that using typedefs in the windows
 headers would require a lot of unrewarded effort. (But you're free to
 disagree.) 

No, that actually makes sense. Once you've worked with the Win32 API and seen how sloppy it is, you're better off just leaving it as it is, and designing well for new stuff. Thanks for the insight. -- dave
Apr 19 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
I don't agree. I always use typedef when interfacing with Win32 (when
appropriate, of course), and I've *never* had a problem, except where I ran
up against an inconsistency with something already (mis-)defined in
windows.d.

"J C Calvarese" <jcc7 cox.net> wrote in message
news:c619f7$1csh$1 digitaldaemon.com...
 In article <Xns94D0503668634dsiebersbc 63.105.9.61>, Dave Sieber says...
"Scott Egan" <scotte tpg.com.aux> wrote:

 I noticed that in std.c.windows.windows the types are all defined as
 aliases.  Would it be better from a type safety and potential



 point-of-view to use typedefs?

I think that each case would have to be looked at, but in general I


- it's always been a problem with the Windows API that so many things are


typedef's and can't be distinguished at all with overloading.
-- 
dave

This has been brought up before. Here's part of Walter's perspective: "One of my early thoughts was also to clean up the win32 type system. Unfortunately, most code plays fast and loose with using C typedefs mixed

 with the underlying types. Microsoft's own sample code is woefully
 inconsistent about it. It's so much easier to just use alias for them and
 not worry about it. Save the clean designs for doing something new, not
 legacy API's." (D/15278)

 I agree with Walter. It seems to me that using typedefs in the windows

 would require a lot of unrewarded effort. (But you're free to disagree.)


 JC

Apr 20 2004
parent reply Dave Sieber <dsieber spamnot.sbcglobal.net> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote:

 I don't agree. I always use typedef when interfacing with Win32 (when
 appropriate, of course), and I've *never* had a problem, except where
 I ran up against an inconsistency with something already (mis-)defined
 in windows.d.

Perhaps if windows.d was cleanly designed (I don't know, haven't used it yet), we actually could use typedef and be happier, which would be a win for all of us. After all, if D can help us rope in and better control Windows, the advantages would be huge. In the C/C++ world, it's a lost cause, IMO. -- dave
Apr 20 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Dave Sieber" <dsieber spamnot.sbcglobal.net> wrote in message
news:Xns94D1990F5444Bdsiebersbc 63.105.9.61...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote:

 I don't agree. I always use typedef when interfacing with Win32 (when
 appropriate, of course), and I've *never* had a problem, except where
 I ran up against an inconsistency with something already (mis-)defined
 in windows.d.

Perhaps if windows.d was cleanly designed (I don't know, haven't used it yet), we actually could use typedef and be happier, which would be a win for all of us.

I believe that is doable
  After all, if D can help us rope in and better control
 Windows, the advantages would be huge.  In the C/C++ world, it's a lost
 cause, IMO.

I have found it thus so far, especially when working with Windows APIs
Apr 20 2004
prev sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
It would indeed. This is an old debate, and I lost to Walter's obdurate
ability to say no.

"Scott Egan" <scotte tpg.com.aux> wrote in message
news:c60g07$2ocd$1 digitaldaemon.com...
 I noticed that in std.c.windows.windows the types are all defined as
 aliases.  Would it be better from a type safety and potential overloading
 point-of-view to use typedefs?

Apr 20 2004
parent reply "Walter" <walter digitalmars.com> writes:
To sum up, my esteemed colleague Matthew took Scott's position, and my
position was I thought our energies would be better spent designing new
functionality than fixing the legacy C windows api.

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c641pr$nhc$1 digitaldaemon.com...
 It would indeed. This is an old debate, and I lost to Walter's obdurate
 ability to say no.

 "Scott Egan" <scotte tpg.com.aux> wrote in message
 news:c60g07$2ocd$1 digitaldaemon.com...
 I noticed that in std.c.windows.windows the types are all defined as
 aliases.  Would it be better from a type safety and potential


 point-of-view to use typedefs?


Apr 21 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
You see, I told you -->

"Walter" <walter digitalmars.com> wrote in message
news:c65dgk$30pe$1 digitaldaemon.com...
 To sum up, my esteemed colleague Matthew took Scott's position, and my
 position was I thought our energies would be better spent designing new
 functionality than fixing the legacy C windows api.

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c641pr$nhc$1 digitaldaemon.com...
 It would indeed. This is an old debate, and I lost to Walter's obdurate


--------- <G>
 ability to say no.

 "Scott Egan" <scotte tpg.com.aux> wrote in message
 news:c60g07$2ocd$1 digitaldaemon.com...
 I noticed that in std.c.windows.windows the types are all defined as
 aliases.  Would it be better from a type safety and potential


 point-of-view to use typedefs?



Apr 21 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Rats and curses! My cunning underlining of "obdurate" was kindly buggered up my
Outlook Express. :(

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c65dmg$310c$2 digitaldaemon.com...
 You see, I told you -->

 "Walter" <walter digitalmars.com> wrote in message
 news:c65dgk$30pe$1 digitaldaemon.com...
 To sum up, my esteemed colleague Matthew took Scott's position, and my
 position was I thought our energies would be better spent designing new
 functionality than fixing the legacy C windows api.

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c641pr$nhc$1 digitaldaemon.com...
 It would indeed. This is an old debate, and I lost to Walter's obdurate


--------- <G>
 ability to say no.

 "Scott Egan" <scotte tpg.com.aux> wrote in message
 news:c60g07$2ocd$1 digitaldaemon.com...
 I noticed that in std.c.windows.windows the types are all defined as
 aliases.  Would it be better from a type safety and potential


 point-of-view to use typedefs?




Apr 21 2004
parent "Walter" <walter digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c65dok$314f$1 digitaldaemon.com...
 Rats and curses!

I know what you mean. I set 8 mouse traps in the attic last night, and this morning the peanut butter was licked clean off of each and every one without setting any off. Tonight I'll bring out the pliers to make them "hair trigger". Nothing keeps one awake at night quite like the sound of gnawing going on right over your head <g>.
Apr 21 2004
prev sibling parent reply "Scott Egan" <scotte tpg.com.aux> writes:
So if it was done for you would you think about accepting it?

Remembering that it is ultimately what we must all use to natively call
Win32.

And I would have thought that building libraries in pure D would be
better/eaiser (esp with intellisense).

BTW I think that there is a general over-reliance on C libraries <duck>.
Surely the aim should be to make D self standing?



"Walter" <walter digitalmars.com> wrote in message
news:c65dgk$30pe$1 digitaldaemon.com...
 To sum up, my esteemed colleague Matthew took Scott's position, and my
 position was I thought our energies would be better spent designing new
 functionality than fixing the legacy C windows api.

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c641pr$nhc$1 digitaldaemon.com...
 It would indeed. This is an old debate, and I lost to Walter's obdurate
 ability to say no.

 "Scott Egan" <scotte tpg.com.aux> wrote in message
 news:c60g07$2ocd$1 digitaldaemon.com...
 I noticed that in std.c.windows.windows the types are all defined as
 aliases.  Would it be better from a type safety and potential


 point-of-view to use typedefs?



Apr 21 2004
parent reply "Walter" <walter digitalmars.com> writes:
Doing this also implies writing new documentation for the Win32 API. That's
just way beyond the scope of what we need to do.

"Scott Egan" <scotte tpg.com.aux> wrote in message
news:c65mqo$e79$1 digitaldaemon.com...
 So if it was done for you would you think about accepting it?

 Remembering that it is ultimately what we must all use to natively call
 Win32.

 And I would have thought that building libraries in pure D would be
 better/eaiser (esp with intellisense).

 BTW I think that there is a general over-reliance on C libraries <duck>.
 Surely the aim should be to make D self standing?



 "Walter" <walter digitalmars.com> wrote in message
 news:c65dgk$30pe$1 digitaldaemon.com...
 To sum up, my esteemed colleague Matthew took Scott's position, and my
 position was I thought our energies would be better spent designing new
 functionality than fixing the legacy C windows api.

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c641pr$nhc$1 digitaldaemon.com...
 It would indeed. This is an old debate, and I lost to Walter's



 ability to say no.

 "Scott Egan" <scotte tpg.com.aux> wrote in message
 news:c60g07$2ocd$1 digitaldaemon.com...
 I noticed that in std.c.windows.windows the types are all defined as
 aliases.  Would it be better from a type safety and potential


 point-of-view to use typedefs?




Apr 21 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
Why does that follow? I don't understand.

"Walter" <walter digitalmars.com> wrote in message
news:c66sgj$2ib1$1 digitaldaemon.com...
 Doing this also implies writing new documentation for the Win32 API. That's
 just way beyond the scope of what we need to do.

 "Scott Egan" <scotte tpg.com.aux> wrote in message
 news:c65mqo$e79$1 digitaldaemon.com...
 So if it was done for you would you think about accepting it?

 Remembering that it is ultimately what we must all use to natively call
 Win32.

 And I would have thought that building libraries in pure D would be
 better/eaiser (esp with intellisense).

 BTW I think that there is a general over-reliance on C libraries <duck>.
 Surely the aim should be to make D self standing?



 "Walter" <walter digitalmars.com> wrote in message
 news:c65dgk$30pe$1 digitaldaemon.com...
 To sum up, my esteemed colleague Matthew took Scott's position, and my
 position was I thought our energies would be better spent designing new
 functionality than fixing the legacy C windows api.

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c641pr$nhc$1 digitaldaemon.com...
 It would indeed. This is an old debate, and I lost to Walter's



 ability to say no.

 "Scott Egan" <scotte tpg.com.aux> wrote in message
 news:c60g07$2ocd$1 digitaldaemon.com...
 I noticed that in std.c.windows.windows the types are all defined as
 aliases.  Would it be better from a type safety and potential


 point-of-view to use typedefs?





Apr 21 2004
parent reply "Walter" <walter digitalmars.com> writes:
I get uncomfortable when I see a prototype for a function that doesn't match
what the documentation says. To me, that screams "bug".

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c66sm4$2ih0$1 digitaldaemon.com...
 Why does that follow? I don't understand.

 "Walter" <walter digitalmars.com> wrote in message
 news:c66sgj$2ib1$1 digitaldaemon.com...
 Doing this also implies writing new documentation for the Win32 API.


 just way beyond the scope of what we need to do.

 "Scott Egan" <scotte tpg.com.aux> wrote in message
 news:c65mqo$e79$1 digitaldaemon.com...
 So if it was done for you would you think about accepting it?

 Remembering that it is ultimately what we must all use to natively



 Win32.

 And I would have thought that building libraries in pure D would be
 better/eaiser (esp with intellisense).

 BTW I think that there is a general over-reliance on C libraries



 Surely the aim should be to make D self standing?



 "Walter" <walter digitalmars.com> wrote in message
 news:c65dgk$30pe$1 digitaldaemon.com...
 To sum up, my esteemed colleague Matthew took Scott's position, and




 position was I thought our energies would be better spent designing




 functionality than fixing the legacy C windows api.

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c641pr$nhc$1 digitaldaemon.com...
 It would indeed. This is an old debate, and I lost to Walter's



 ability to say no.

 "Scott Egan" <scotte tpg.com.aux> wrote in message
 news:c60g07$2ocd$1 digitaldaemon.com...
 I noticed that in std.c.windows.windows the types are all






 aliases.  Would it be better from a type safety and potential


 point-of-view to use typedefs?






Apr 21 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
That's not what I'm talking about.

In std.windows.registry I defined HKEY as a typedef, rather than an alias. This
means that I cannot pass a HKEY to, say, CloseHandle(), and no-one can pass a
HANDLE to RegCreateKey().

As I've said many times, I totally fail to see any flaw in this approach, and
I've not yet experienced one in practice.

"Walter" <walter digitalmars.com> wrote in message
news:c67i3b$kkk$1 digitaldaemon.com...
 I get uncomfortable when I see a prototype for a function that doesn't match
 what the documentation says. To me, that screams "bug".

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c66sm4$2ih0$1 digitaldaemon.com...
 Why does that follow? I don't understand.

 "Walter" <walter digitalmars.com> wrote in message
 news:c66sgj$2ib1$1 digitaldaemon.com...
 Doing this also implies writing new documentation for the Win32 API.


 just way beyond the scope of what we need to do.

 "Scott Egan" <scotte tpg.com.aux> wrote in message
 news:c65mqo$e79$1 digitaldaemon.com...
 So if it was done for you would you think about accepting it?

 Remembering that it is ultimately what we must all use to natively



 Win32.

 And I would have thought that building libraries in pure D would be
 better/eaiser (esp with intellisense).

 BTW I think that there is a general over-reliance on C libraries



 Surely the aim should be to make D self standing?



 "Walter" <walter digitalmars.com> wrote in message
 news:c65dgk$30pe$1 digitaldaemon.com...
 To sum up, my esteemed colleague Matthew took Scott's position, and




 position was I thought our energies would be better spent designing




 functionality than fixing the legacy C windows api.

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c641pr$nhc$1 digitaldaemon.com...
 It would indeed. This is an old debate, and I lost to Walter's



 ability to say no.

 "Scott Egan" <scotte tpg.com.aux> wrote in message
 news:c60g07$2ocd$1 digitaldaemon.com...
 I noticed that in std.c.windows.windows the types are all






 aliases.  Would it be better from a type safety and potential


 point-of-view to use typedefs?







Apr 21 2004
next sibling parent "Walter" <walter digitalmars.com> writes:
I've encountered enough inconsistencies in windows code to make making them
typedefs a nuisance. The documentation problem comes in when inout and out
parameters are folded in.

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c67jas$mgd$1 digitaldaemon.com...
 That's not what I'm talking about.

 In std.windows.registry I defined HKEY as a typedef, rather than an alias.

 means that I cannot pass a HKEY to, say, CloseHandle(), and no-one can

 HANDLE to RegCreateKey().

 As I've said many times, I totally fail to see any flaw in this approach,

 I've not yet experienced one in practice.

 "Walter" <walter digitalmars.com> wrote in message
 news:c67i3b$kkk$1 digitaldaemon.com...
 I get uncomfortable when I see a prototype for a function that doesn't


 what the documentation says. To me, that screams "bug".

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c66sm4$2ih0$1 digitaldaemon.com...
 Why does that follow? I don't understand.

 "Walter" <walter digitalmars.com> wrote in message
 news:c66sgj$2ib1$1 digitaldaemon.com...
 Doing this also implies writing new documentation for the Win32 API.


 just way beyond the scope of what we need to do.

 "Scott Egan" <scotte tpg.com.aux> wrote in message
 news:c65mqo$e79$1 digitaldaemon.com...
 So if it was done for you would you think about accepting it?

 Remembering that it is ultimately what we must all use to natively



 Win32.

 And I would have thought that building libraries in pure D would





 better/eaiser (esp with intellisense).

 BTW I think that there is a general over-reliance on C libraries



 Surely the aim should be to make D self standing?



 "Walter" <walter digitalmars.com> wrote in message
 news:c65dgk$30pe$1 digitaldaemon.com...
 To sum up, my esteemed colleague Matthew took Scott's position,






 my
 position was I thought our energies would be better spent






 new
 functionality than fixing the legacy C windows api.

 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:c641pr$nhc$1 digitaldaemon.com...
 It would indeed. This is an old debate, and I lost to Walter's



 ability to say no.

 "Scott Egan" <scotte tpg.com.aux> wrote in message
 news:c60g07$2ocd$1 digitaldaemon.com...
 I noticed that in std.c.windows.windows the types are all






 aliases.  Would it be better from a type safety and








 overloading
 point-of-view to use typedefs?








Apr 24 2004
prev sibling parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Your design is good.  But what if there is some API that Microsoft 
documented to work like this:
	VOID DoStuffWithKey(HANDLE);
then you are stuck with having to fix Microsoft's broken design...your 
code must use the Right definition, which is different than the one that 
is in the docs.

Personally, I'm supportive of you if you want to track down all of these 
problems and fix the Windows API.  But I agree with Walter that it's 
probably a lot of work with little real gain :(  More power to ya, though.

Russ

Matthew wrote:
 That's not what I'm talking about.
 
 In std.windows.registry I defined HKEY as a typedef, rather than an alias. This
 means that I cannot pass a HKEY to, say, CloseHandle(), and no-one can pass a
 HANDLE to RegCreateKey().
 
 As I've said many times, I totally fail to see any flaw in this approach, and
 I've not yet experienced one in practice.
 
 "Walter" <walter digitalmars.com> wrote in message
 news:c67i3b$kkk$1 digitaldaemon.com...
 
I get uncomfortable when I see a prototype for a function that doesn't match
what the documentation says. To me, that screams "bug".

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c66sm4$2ih0$1 digitaldaemon.com...

Why does that follow? I don't understand.

"Walter" <walter digitalmars.com> wrote in message
news:c66sgj$2ib1$1 digitaldaemon.com...

Doing this also implies writing new documentation for the Win32 API.


That's
just way beyond the scope of what we need to do.

"Scott Egan" <scotte tpg.com.aux> wrote in message
news:c65mqo$e79$1 digitaldaemon.com...

So if it was done for you would you think about accepting it?

Remembering that it is ultimately what we must all use to natively



call
Win32.

And I would have thought that building libraries in pure D would be
better/eaiser (esp with intellisense).

BTW I think that there is a general over-reliance on C libraries



<duck>.
Surely the aim should be to make D self standing?



"Walter" <walter digitalmars.com> wrote in message
news:c65dgk$30pe$1 digitaldaemon.com...

To sum up, my esteemed colleague Matthew took Scott's position, and




my
position was I thought our energies would be better spent designing




new
functionality than fixing the legacy C windows api.

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c641pr$nhc$1 digitaldaemon.com...

It would indeed. This is an old debate, and I lost to Walter's



obdurate
ability to say no.

"Scott Egan" <scotte tpg.com.aux> wrote in message
news:c60g07$2ocd$1 digitaldaemon.com...

I noticed that in std.c.windows.windows the types are all






defined as
aliases.  Would it be better from a type safety and potential


overloading
point-of-view to use typedefs?








May 03 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 Your design is good.  But what if there is some API that Microsoft
 documented to work like this:
 VOID DoStuffWithKey(HANDLE);
 then you are stuck with having to fix Microsoft's broken design...your
 code must use the Right definition, which is different than the one that
 is in the docs.

This is only an issue with an automated .h=>.d tool. And any decent implementation of that could keep bad_function lists, in which a map of the arg # and good/bad types could be recorded and acted upon.
 Personally, I'm supportive of you if you want to track down all of these
 problems and fix the Windows API.  But I agree with Walter that it's
 probably a lot of work with little real gain :(  More power to ya, though.

If it's all done by one person, in one go, of course. But it's really as simple as making HKEY, HFONT etc. typedefs, and then going from there. As I've said over and over when this has been discussed, doing this has caused me precisely ZERO problems or extra work thus far.
 Russ

 Matthew wrote:
 That's not what I'm talking about.

 In std.windows.registry I defined HKEY as a typedef, rather than an alias.


 means that I cannot pass a HKEY to, say, CloseHandle(), and no-one can pass a
 HANDLE to RegCreateKey().

 As I've said many times, I totally fail to see any flaw in this approach, and
 I've not yet experienced one in practice.

 "Walter" <walter digitalmars.com> wrote in message
 news:c67i3b$kkk$1 digitaldaemon.com...

I get uncomfortable when I see a prototype for a function that doesn't match
what the documentation says. To me, that screams "bug".

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c66sm4$2ih0$1 digitaldaemon.com...

Why does that follow? I don't understand.

"Walter" <walter digitalmars.com> wrote in message
news:c66sgj$2ib1$1 digitaldaemon.com...

Doing this also implies writing new documentation for the Win32 API.


That's
just way beyond the scope of what we need to do.

"Scott Egan" <scotte tpg.com.aux> wrote in message
news:c65mqo$e79$1 digitaldaemon.com...

So if it was done for you would you think about accepting it?

Remembering that it is ultimately what we must all use to natively



call
Win32.

And I would have thought that building libraries in pure D would be
better/eaiser (esp with intellisense).

BTW I think that there is a general over-reliance on C libraries



<duck>.
Surely the aim should be to make D self standing?



"Walter" <walter digitalmars.com> wrote in message
news:c65dgk$30pe$1 digitaldaemon.com...

To sum up, my esteemed colleague Matthew took Scott's position, and




my
position was I thought our energies would be better spent designing




new
functionality than fixing the legacy C windows api.

"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c641pr$nhc$1 digitaldaemon.com...

It would indeed. This is an old debate, and I lost to Walter's



obdurate
ability to say no.

"Scott Egan" <scotte tpg.com.aux> wrote in message
news:c60g07$2ocd$1 digitaldaemon.com...

I noticed that in std.c.windows.windows the types are all






defined as
aliases.  Would it be better from a type safety and potential


overloading
point-of-view to use typedefs?









May 03 2004