Comment #0 by ilyayaroshenko — 2017-08-12T12:54:00Z
This
extern(C) shared static this()
{
...
}
and
pragma(mangle, "a_name")
extern(C) shared static this()
{
...
}
should be called in betterC single file program with main.
If I am not wrong they can be called before C main, in start.
OS: macos
DMD version: 2.075
Comment #1 by ilyayaroshenko — 2017-08-12T12:56:55Z
And extern(C++), extern(D) can/should work too.
Comment #2 by petar.p.kirov — 2017-08-13T13:42:38Z
AFAIK, C doesn't have static constructors, only C++ has, so your example should be:
extern(C++) shared static this()
{
// ...
}
Of course extern (D) should work too:
extern(D) shared static this()
{
// ...
}
I'm not sure if `pragma(mangle, ...) [shared] static this()` should be allowed as static constructors / destructors are meant to be called only once and only by the runtime.
Comment #3 by ilyayaroshenko — 2017-08-14T04:35:47Z
(In reply to ZombineDev from comment #2)
> AFAIK, C doesn't have static constructors, only C++ has, so your example
> should be:
>
> extern(C++) shared static this()
> {
> // ...
> }
>
> Of course extern (D) should work too:
>
> extern(D) shared static this()
> {
> // ...
> }
>
> I'm not sure if `pragma(mangle, ...) [shared] static this()` should be
> allowed as static constructors / destructors are meant to be called only
> once and only by the runtime.
__attribute__ ((constructor)) is in C. It can be called in start before main, without DRuntime.
Comment #4 by petar.p.kirov — 2017-08-27T09:34:56Z
> __attribute__ ((constructor)) is in C. It can be called in start before main, without DRuntime.
Technically this is a compiler extension, not a feature part of the ISO C standard. My point was that C standard does not require such feature and therefore we shouldn't rely on its existence.
On the other hand, C++ does due to the need to be able to call class constructors for static/global variables.
Comment #5 by petar.p.kirov — 2017-08-27T09:35:51Z
> It can be called in start before main, without DRuntime.
Agreed.
Comment #6 by schveiguy — 2017-09-13T15:53:24Z
How is the order determined? D static ctors are written assuming the import graph can be used to deduce a valid ordering of calls.
If this were to be implemented, an extern(C) static ctor would have a completely different meaning. I would be against this.
In any case, this is an enhancement, not a blocker.
Comment #7 by dfj1esp02 — 2017-09-14T10:05:43Z
(In reply to Steven Schveighoffer from comment #6)
> D static ctors
C abi is requested with extern(C) here, sure they are different.
Comment #8 by schveiguy — 2017-09-14T12:55:39Z
(In reply to anonymous4 from comment #7)
> C abi is requested with extern(C) here, sure they are different.
Essentially, what I'm saying is:
mod1.d:
int x;
extern(C) static this()
{
x = 5;
}
mod2.d:
import mod1;
int y;
extern(C) static this()
{
y = x + 1; // should be 6, but could be 1 if executed in the wrong order
}
Druntime knows how to make this work. C does not. You are changing the semantic meaning of static this() by putting an extern(C) on it, and I don't think it's a good idea. People are used to this "just working".
You also likely will break code, as I think there are many files with extern(C): at the top, for which this would change the semantics.
Comment #9 by dfj1esp02 — 2017-09-18T09:05:19Z
(In reply to Steven Schveighoffer from comment #8)
> People are used to this "just working".
Same problem for other usage of extern(C).
Comment #10 by schveiguy — 2017-09-18T12:25:04Z
(In reply to anonymous4 from comment #9)
> (In reply to Steven Schveighoffer from comment #8)
> > People are used to this "just working".
> Same problem for other usage of extern(C).
How so?
void foo();
extern(C) void foo();
What is the difference? Don't both work exactly the same? As far as I know, the only difference is mangling.
There is also no other precedent where a compiled D program only works properly if you link in the correct order.
Comment #11 by dfj1esp02 — 2017-09-20T12:35:45Z
(In reply to Steven Schveighoffer from comment #10)
> There is also no other precedent where a compiled D program only works
> properly if you link in the correct order.
Issue 7063
Comment #12 by schveiguy — 2017-09-20T14:37:15Z
(In reply to anonymous4 from comment #11)
> (In reply to Steven Schveighoffer from comment #10)
> > There is also no other precedent where a compiled D program only works
> > properly if you link in the correct order.
>
> Issue 7063
So that program works properly if you link in a different order?
Comment #13 by dfj1esp02 — 2017-09-21T15:41:13Z
Looks like it.
Comment #14 by schveiguy — 2017-09-21T15:52:21Z
Changing the link order does nothing, because there is one file.
In other words, issue 7063 is a bug, no matter how you build it. It shouldn't build (hence accepts-invalid).
This proposal is different -- if you link in one order, it will work as expected. Change that order, and it will blow up. IMO, we should not introduce this kind of problem.
Comment #15 by dfj1esp02 — 2017-09-21T16:57:31Z
(In reply to Steven Schveighoffer from comment #14)
> Changing the link order does nothing, because there is one file.
It requires two files to work.
> In other words, issue 7063 is a bug, no matter how you build it. It
> shouldn't build (hence accepts-invalid).
But for D abi it would build and just work.