digitalmars.D.bugs - Buglet: extern (Windows) even on linux?
- Andy Friesen (4/4) May 03 2004 The linux version of DMD will blithely allow you to declare functions as...
- Walter (3/6) May 04 2004 It might come in handy when writing portable code.
- Daniel Horn (18/29) May 04 2004 if we can count on extern(Windows) to work on linux
- Walter (9/38) May 05 2004 It's a good idea, but a couple problems with it are:
- Daniel Horn (13/63) May 05 2004 this is why I proposed a different keyword that would do the platform
- Walter (13/76) May 10 2004 The problem (as I see it) is that gl.h, for some inexplicable reason, ch...
The linux version of DMD will blithely allow you to declare functions as being extern (Windows), even though this isn't very useful. Should it? (maybe this is convenient when cross-compiling or something) -- andy
May 03 2004
"Andy Friesen" <andy ikagames.com> wrote in message news:c779ec$1p8i$1 digitaldaemon.com...The linux version of DMD will blithely allow you to declare functions as being extern (Windows), even though this isn't very useful. Should it? (maybe this is convenient when cross-compiling or something)It might come in handy when writing portable code.
May 04 2004
if we can count on extern(Windows) to work on linux why not call it extern(PlatformDLL) or just extern(dll) then the platform can choose the calling convention it pleases for loading a standard dynamic lib in linux that would be .so--in windows that would be .dll on mac it would by .dylib that way we wouldn't need to paste the header thrice for 3 platforms (n times for n platforms) or need more powerful version() stuff under linux leaving extern(Windows) undefined in the spec is a recipe for disaster though--it's a bug thats going to have to be supported for a long, long time. Another benefit: sometimes linux programs want to load .dll's (like mplayer loads dll's ) then we could use extern(Windows) to specify the WINDOWS calling convention, instead of leaving it at the linux one Walter wrote:"Andy Friesen" <andy ikagames.com> wrote in message news:c779ec$1p8i$1 digitaldaemon.com...The linux version of DMD will blithely allow you to declare functions as being extern (Windows), even though this isn't very useful. Should it? (maybe this is convenient when cross-compiling or something)It might come in handy when writing portable code.
May 04 2004
It's a good idea, but a couple problems with it are: 1) in Win32, you can have C functions exported from DLL's, too. extern(Windows) is not a dll specific thing, it is specific to Microsoft API conventions. 2) if you use inline asm, that depends on the calling conventions, having extern(Windows) mean a different calling convention on different platforms will muck it up. "Daniel Horn" <hellcatv hotmail.com> wrote in message news:c79dmh$1vv6$1 digitaldaemon.com...if we can count on extern(Windows) to work on linux why not call it extern(PlatformDLL) or just extern(dll) then the platform can choose the calling convention it pleases for loading a standard dynamic lib in linux that would be .so--in windows that would be .dll on mac it would by .dylib that way we wouldn't need to paste the header thrice for 3 platforms (n times for n platforms) or need more powerful version() stuff under linux leaving extern(Windows) undefined in the spec is a recipe for disaster though--it's a bug thats going to have to be supported for a long, long time. Another benefit: sometimes linux programs want to load .dll's (like mplayer loads dll's ) then we could use extern(Windows) to specify the WINDOWS calling convention, instead of leaving it at the linux one Walter wrote:"Andy Friesen" <andy ikagames.com> wrote in message news:c779ec$1p8i$1 digitaldaemon.com...The linux version of DMD will blithely allow you to declare functions as being extern (Windows), even though this isn't very useful. Should it? (maybe this is convenient when cross-compiling or something)It might come in handy when writing portable code.
May 05 2004
this is why I proposed a different keyword that would do the platform default extern(PlatformDll) extern(C) would take care of the things that are C for all platforms It's important to make importing C headers as easy as possible Having to paste the gl.h 3 times, one for win, mac and linux is just unacceptible. What about SGI, BSD, ... ... it's unmanagable The other option is to increase the power of version to let you specify different calling conventions for a function depending on the platform. I think improving version to deal with this simple case is important for porting headers over :-) --Daniel Walter wrote:It's a good idea, but a couple problems with it are: 1) in Win32, you can have C functions exported from DLL's, too. extern(Windows) is not a dll specific thing, it is specific to Microsoft API conventions. 2) if you use inline asm, that depends on the calling conventions, having extern(Windows) mean a different calling convention on different platforms will muck it up. "Daniel Horn" <hellcatv hotmail.com> wrote in message news:c79dmh$1vv6$1 digitaldaemon.com...if we can count on extern(Windows) to work on linux why not call it extern(PlatformDLL) or just extern(dll) then the platform can choose the calling convention it pleases for loading a standard dynamic lib in linux that would be .so--in windows that would be .dll on mac it would by .dylib that way we wouldn't need to paste the header thrice for 3 platforms (n times for n platforms) or need more powerful version() stuff under linux leaving extern(Windows) undefined in the spec is a recipe for disaster though--it's a bug thats going to have to be supported for a long, long time. Another benefit: sometimes linux programs want to load .dll's (like mplayer loads dll's ) then we could use extern(Windows) to specify the WINDOWS calling convention, instead of leaving it at the linux one Walter wrote:"Andy Friesen" <andy ikagames.com> wrote in message news:c779ec$1p8i$1 digitaldaemon.com...The linux version of DMD will blithely allow you to declare functions as being extern (Windows), even though this isn't very useful. Should it? (maybe this is convenient when cross-compiling or something)It might come in handy when writing portable code.
May 05 2004
"Walter" <newshound digitalmars.com> The problem (as I see it) is that gl.h, for some inexplicable reason, chose to use different calling conventions on different platforms, rather than the C calling convention. Also, there is no standard dll calling convention (even on Windows). And (correct me if I'm wrong) there are no calling conventions (dll or otherwise) on other platforms other than the C calling conventions. "Daniel Horn" <hellcatv hotmail.com> wrote in message news:c7bi3v$290g$1 digitaldaemon.com...this is why I proposed a different keyword that would do the platform default extern(PlatformDll) extern(C) would take care of the things that are C for all platforms It's important to make importing C headers as easy as possible Having to paste the gl.h 3 times, one for win, mac and linux is just unacceptible. What about SGI, BSD, ... ... it's unmanagable The other option is to increase the power of version to let you specify different calling conventions for a function depending on the platform. I think improving version to deal with this simple case is important for porting headers over :-) --Daniel Walter wrote:APIIt's a good idea, but a couple problems with it are: 1) in Win32, you can have C functions exported from DLL's, too. extern(Windows) is not a dll specific thing, it is specific to Microsofthavingconventions. 2) if you use inline asm, that depends on the calling conventions,platformsextern(Windows) mean a different calling convention on differentaswill muck it up. "Daniel Horn" <hellcatv hotmail.com> wrote in message news:c79dmh$1vv6$1 digitaldaemon.com...if we can count on extern(Windows) to work on linux why not call it extern(PlatformDLL) or just extern(dll) then the platform can choose the calling convention it pleases for loading a standard dynamic lib in linux that would be .so--in windows that would be .dll on mac it would by .dylib that way we wouldn't need to paste the header thrice for 3 platforms (n times for n platforms) or need more powerful version() stuff under linux leaving extern(Windows) undefined in the spec is a recipe for disaster though--it's a bug thats going to have to be supported for a long, long time. Another benefit: sometimes linux programs want to load .dll's (like mplayer loads dll's ) then we could use extern(Windows) to specify the WINDOWS calling convention, instead of leaving it at the linux one Walter wrote:"Andy Friesen" <andy ikagames.com> wrote in message news:c779ec$1p8i$1 digitaldaemon.com...The linux version of DMD will blithely allow you to declare functionsit?being extern (Windows), even though this isn't very useful. Should(maybe this is convenient when cross-compiling or something)It might come in handy when writing portable code.
May 10 2004