D - alias vs typedef
- Scott Egan (3/3) Apr 19 2004 I noticed that in std.c.windows.windows the types are all defined as
- Dave Sieber (6/9) Apr 19 2004 I think that each case would have to be looked at, but in general I agre...
- J C Calvarese (11/20) Apr 19 2004 This has been brought up before. Here's part of Walter's perspective:
- Dave Sieber (7/10) Apr 19 2004 No, that actually makes sense. Once you've worked with the Win32 API and...
- Matthew (11/34) Apr 20 2004 I don't agree. I always use typedef when interfacing with Win32 (when
- Dave Sieber (8/12) Apr 20 2004 Perhaps if windows.d was cleanly designed (I don't know, haven't used it...
- Matthew (4/15) Apr 20 2004 I believe that is doable
- Matthew (4/7) Apr 20 2004 It would indeed. This is an old debate, and I lost to Walter's obdurate
- Walter (6/15) Apr 21 2004 To sum up, my esteemed colleague Matthew took Scott's position, and my
- Matthew (5/19) Apr 21 2004 You see, I told you -->
- Matthew (4/23) Apr 21 2004 Rats and curses! My cunning underlining of "obdurate" was kindly buggere...
- Walter (8/9) Apr 21 2004 I know what you mean. I set 8 mouse traps in the attic last night, and t...
- Scott Egan (9/27) Apr 21 2004 So if it was done for you would you think about accepting it?
- Walter (5/35) Apr 21 2004 Doing this also implies writing new documentation for the Win32 API. Tha...
- Matthew (3/46) Apr 21 2004 Why does that follow? I don't understand.
- Walter (10/59) Apr 21 2004 I get uncomfortable when I see a prototype for a function that doesn't m...
- Matthew (8/70) Apr 21 2004 That's not what I'm talking about.
- Walter (13/86) Apr 24 2004 I've encountered enough inconsistencies in windows code to make making t...
- Russ Lewis (11/96) May 03 2004 Your design is good. But what if there is some API that Microsoft
- Matthew (8/104) May 03 2004 This is only an issue with an automated .h=>.d tool. And any decent
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
"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
In article <Xns94D0503668634dsiebersbc 63.105.9.61>, Dave Sieber says..."Scott Egan" <scotte tpg.com.aux> wrote: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." (http://www.digitalmars.com/drn-bin/wwwnews?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.) JCI 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
Dave Sieber <dsieber spamnot.sbcglobal.net> 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
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...overloading"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 potentialagree -point-of-view to use typedefs?I think that each case would have to be looked at, but in general IC- it's always been a problem with the Windows API that so many things areintypedef's and can't be distinguished at all with overloading. -- daveThis 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 mixedwith 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." (http://www.digitalmars.com/drn-bin/wwwnews?D/15278) I agree with Walter. It seems to me that using typedefs in the windowsheaderswould require a lot of unrewarded effort. (But you're free to disagree.) JC
Apr 20 2004
"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
"Dave Sieber" <dsieber spamnot.sbcglobal.net> wrote in message news:Xns94D1990F5444Bdsiebersbc 63.105.9.61..."Matthew" <matthew.hat stlsoft.dot.org> wrote:I believe that is doableI 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.I have found it thus so far, especially when working with Windows APIs
Apr 20 2004
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
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...overloadingI noticed that in std.c.windows.windows the types are all defined as aliases. Would it be better from a type safety and potentialpoint-of-view to use typedefs?
Apr 21 2004
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...--------- <G>It would indeed. This is an old debate, and I lost to Walter's obdurateability to say no. "Scott Egan" <scotte tpg.com.aux> wrote in message news:c60g07$2ocd$1 digitaldaemon.com...overloadingI noticed that in std.c.windows.windows the types are all defined as aliases. Would it be better from a type safety and potentialpoint-of-view to use typedefs?
Apr 21 2004
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...--------- <G>It would indeed. This is an old debate, and I lost to Walter's obdurateability to say no. "Scott Egan" <scotte tpg.com.aux> wrote in message news:c60g07$2ocd$1 digitaldaemon.com...overloadingI noticed that in std.c.windows.windows the types are all defined as aliases. Would it be better from a type safety and potentialpoint-of-view to use typedefs?
Apr 21 2004
"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
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...overloadingI noticed that in std.c.windows.windows the types are all defined as aliases. Would it be better from a type safety and potentialpoint-of-view to use typedefs?
Apr 21 2004
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...obdurateTo 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'sability to say no. "Scott Egan" <scotte tpg.com.aux> wrote in message news:c60g07$2ocd$1 digitaldaemon.com...overloadingI noticed that in std.c.windows.windows the types are all defined as aliases. Would it be better from a type safety and potentialpoint-of-view to use typedefs?
Apr 21 2004
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...obdurateTo 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'sability to say no. "Scott Egan" <scotte tpg.com.aux> wrote in message news:c60g07$2ocd$1 digitaldaemon.com...overloadingI noticed that in std.c.windows.windows the types are all defined as aliases. Would it be better from a type safety and potentialpoint-of-view to use typedefs?
Apr 21 2004
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...That'sDoing this also implies writing new documentation for the Win32 API.calljust 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<duck>.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 librariesmySurely 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, andnewposition was I thought our energies would be better spent designingdefined asobduratefunctionality 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'sability 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 alloverloadingaliases. Would it be better from a type safety and potentialpoint-of-view to use typedefs?
Apr 21 2004
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...That'sDoing this also implies writing new documentation for the Win32 API.calljust 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<duck>.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 librariesmySurely 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, andnewposition was I thought our energies would be better spent designingdefined asobduratefunctionality 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'sability 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 alloverloadingaliases. Would it be better from a type safety and potentialpoint-of-view to use typedefs?
Apr 21 2004
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.Thismeans that I cannot pass a HKEY to, say, CloseHandle(), and no-one canpass aHANDLE to RegCreateKey(). As I've said many times, I totally fail to see any flaw in this approach,andI've not yet experienced one in practice. "Walter" <walter digitalmars.com> wrote in message news:c67i3b$kkk$1 digitaldaemon.com...matchI get uncomfortable when I see a prototype for a function that doesn'tbewhat 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...That'sDoing this also implies writing new documentation for the Win32 API.calljust 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 nativelyWin32. And I would have thought that building libraries in pure D wouldand<duck>.better/eaiser (esp with intellisense). BTW I think that there is a general over-reliance on C librariesSurely 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,designingmyposition was I thought our energies would be better spentpotentialnewdefined asobduratefunctionality 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'sability 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 allaliases. Would it be better from a type safety andoverloadingpoint-of-view to use typedefs?
Apr 24 2004
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...That'sDoing this also implies writing new documentation for the Win32 API.calljust 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<duck>.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 librariesmySurely 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, andnewposition was I thought our energies would be better spent designingdefined asobduratefunctionality 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'sability 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 alloverloadingaliases. Would it be better from a type safety and potentialpoint-of-view to use typedefs?
May 03 2004
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:ThisThat'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...That'sDoing this also implies writing new documentation for the Win32 API.calljust 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<duck>.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 librariesmySurely 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, andnewposition was I thought our energies would be better spent designingdefined asobduratefunctionality 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'sability 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 alloverloadingaliases. Would it be better from a type safety and potentialpoint-of-view to use typedefs?
May 03 2004