View mode: basic / threaded / horizontal-split · Log in · Help
July 10, 2007
Re: version and extern problems
Walter Bright wrote:
> Carlos Santander wrote:
>> I'm guessing this would be the default calling convention for the 
>> system. If the system was written in C++ (BeOS?), would it have to 
>> mean "extern(C++)"? If someone wrote an OS in D, would it just be 
>> "extern(D)"? Or would it just be specified that "System" means 
>> "Windows" on Windows and "C" everywhere else?
> 
> No, it would be what is necessary to interface to packages that pick 
> pointless things like "Windows" calling conventions. If lots of C 
> packages used "FooBar" calling conventions on XXX, then it would mean 
> "FooBar" on that system.

By this argument, it could just as easily be called "Broken".  I am 
concerned that calling it "System" will encourage widespread use...which 
is a step in exactly what you said was the wrong direction.

Did you see the post about using strings for extern?  That seemed like 
an elegant solution to me:

version(Windows)
  const char[] myExternAlias = "Windows";
else
  const char[] myExternAlias = "C";

extern(myExternAlias) void foo();
July 10, 2007
Re: version and extern problems
Chris Miller wrote:
> I don't know; why not let it just be a string literal...
> 
> version(Windows)
>     const char[] mylibcall = "Windows";
> else
>     const char[] mylibcall = "C";
> 
> extern(mylibcall) void function() foo;

It's the old chicken-and-egg problem of forward references.
July 10, 2007
Re: version and extern problems
Don Clugston wrote:
> IMHO, extern(System) would be fantastic.

It's a kludge, but a very useful one. I'll fold it into the next update.
July 10, 2007
Re: version and extern problems
torhu wrote:
> Yes, but what the Pascal convention?

People who #ifdef their C code to use Pascal on one platform and C on 
another should be excommunicated, and their software should be stricken 
from all monuments.
July 10, 2007
Re: version and extern problems
"Walter Bright" <newshound1@digitalmars.com> wrote in message 
news:f70mvo$22e7$1@digitalmars.com...
>
> It's the old chicken-and-egg problem of forward references.

Mind elaborating?  I can't see how this is a forward reference issue.
July 10, 2007
Re: version and extern problems
Reply to Jarrett,

> "Walter Bright" <newshound1@digitalmars.com> wrote in message
> news:f70mvo$22e7$1@digitalmars.com...
> 
>> It's the old chicken-and-egg problem of forward references.
>> 
> Mind elaborating?  I can't see how this is a forward reference issue.
> 

extern(A) const char[] A = "foo";

but as long as you don't worry about symbol names untill you are making .o 
files that isn't a problem (I would think).
July 10, 2007
Re: version and extern problems
On Tue, 10 Jul 2007 16:55:47 -0400, BCS <ao@pathlink.com> wrote:

> Reply to Jarrett,
>
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message
>> news:f70mvo$22e7$1@digitalmars.com...
>>
>>> It's the old chicken-and-egg problem of forward references.
>>>
>> Mind elaborating?  I can't see how this is a forward reference issue.
>>
>
> extern(A) const char[] A = "foo";
>
> but as long as you don't worry about symbol names untill you are making  
> .o files that isn't a problem (I would think).

I think problems like that exist all over the place; just don't do it.

int foo = foo.init;


I would like to know what Walter is referring to too.
July 10, 2007
Re: version and extern problems
Jarrett Billingsley wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message 
> news:f70mvo$22e7$1@digitalmars.com...
>> It's the old chicken-and-egg problem of forward references.
> 
> Mind elaborating?  I can't see how this is a forward reference issue. 

Sure. What if the string is a const string defined after it is used?
July 10, 2007
Re: version and extern problems
Reply to Walter,

> Jarrett Billingsley wrote:
> 
>> "Walter Bright" <newshound1@digitalmars.com> wrote in message
>> news:f70mvo$22e7$1@digitalmars.com...
>> 
>>> It's the old chicken-and-egg problem of forward references.
>>> 
>> Mind elaborating?  I can't see how this is a forward reference issue.
>> 
> Sure. What if the string is a const string defined after it is used?
> 

That is one thing I have never understood: why does lexical order ever (outside 
of statement lists e.i. function) ever cause an issue?

I would expect that all of these issues could be removed by having one pass 
over the AST find the symbols (without getting types or anything else). Then 
another pass starts filling them out by reclusively evaluating symbols.

The only issue I see right off involve non-determinism of some things like 
static asserts and ifs and how errors are found. But I think that that could 
be removed (or rendered irrelevant) for cases where errors aren't present.

Then again, my experience with compilers stops just barely after lexers.

However I /am/ genuinely interested in your thoughts on this.
July 11, 2007
Re: version and extern problems
BCS wrote:
> That is one thing I have never understood: why does lexical order ever 
> (outside of statement lists e.i. function) ever cause an issue?

const string x = "abc" ~ foo;
const string foo = x[1..4];
1 2 3 4 5 6
Top | Discussion index | About this forum | D home