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

"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.

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.
> 
> 

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.
> >
> >

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.
>>>
>>>
> 
> 
> 

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:
> > 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.
> >>>
> >>>
> >
> >
> >