www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Cannot compile betterC app in windows using stderr

reply Abby <abby gmail.com> writes:
I have a simple


**dub.sdl**
```
name "test"
targetType "executable"
buildOptions "betterC"
```

**app.d**
```
module test;
import core.stdc.stdio : fprintf, stderr;

extern(C) int main(string[] args)
{
	fprintf(stderr, "Test\n",);
	return 0;
}
```



When I'm trying to compile this on windows with latest dmd or ldc 
I get
```Performing "debug" build using C:\D\dmd2\windows\bin64\dmd.exe 
for x86_64.
test ~master: building configuration "application"...
Linking...
test.obj : error LNK2019: unresolved external symbol stderr 
referenced in function main
.dub\build\application-debug-windows-x86_64-dmd_v2.098.1-dirty-FB5231E74956BBA34BF96
F450A8342C\test.exe : fatal error LNK1120: 1 unresolved externals
Error: linker exited with status 1120
C:\D\dmd2\windows\bin64\dmd.exe failed with exit code 1.
```


Works with dmd-2.091.0

Any idea what might be the problem here?
Feb 01 2022
next sibling parent reply forkit <forkit gmail.com> writes:
On Wednesday, 2 February 2022 at 01:24:30 UTC, Abby wrote:



a link error with the 64bit version of dmd ??

try: -m32



 Feb 01 2022



  parent reply Abby <abby gmail.com>  writes:


On Wednesday, 2 February 2022 at 03:34:29 UTC, forkit wrote:

 On Wednesday, 2 February 2022 at 01:24:30 UTC, Abby wrote:



 a link error with the 64bit version of dmd ??

 try: -m32


Hi did not help

```
dub build --arch=x86_64



The following compiler flags have been specified in the package 
description
file. They are handled by DUB and direct use in packages is 
discouraged.
Alternatively, you can set the DFLAGS environment variable to 
pass custom flags
to the compiler, or use one of the suggestions below:

-m32: Use --arch=x86/--arch=x86_64/--arch=x86_mscoff to specify 
the target architecture, e.g. 'dub build --arch=x86_64'

Performing "debug" build using C:\D\dmd2\windows\bin64\dmd.exe 
for x86_64.
test ~master: building configuration "application"...
Linking...
test.obj : error LNK2019: unresolved external symbol stderr 
referenced in function main
.dub\build\application-debug-windows-x86_64-dmd_v2.098.1-dirty-ED981EB8716B85E9E2580
86FAF4E89B\test.exe : fatal error LNK1120: 1 unresolved externals
Error: linker exited with status 1120
C:\D\dmd2\windows\bin64\dmd.exe failed with exit code 1.
```



 Feb 01 2022



  parent  forkit <forkit gmail.com>  writes:


On Wednesday, 2 February 2022 at 06:20:39 UTC, Abby wrote:


I don't know about dub. never used it.

I can say, that your code will compile and run fine if compiled 
with dmd using:

dmd -m32 -betterC mycode.d

but not

dmd -m64 -betterC mycode.d

it seems like a MSVC linking error (possibly unresolved 
references or something).

Also, this is a Windows issue. The same code will compile fine on 
linux -32 or -m64

Someone with more expertise will need to troubleshoot this 
further ;-)



 Feb 01 2022



prev sibling  parent reply Basile B. <b2.temp gmx.com>  writes:


On Wednesday, 2 February 2022 at 01:24:30 UTC, Abby wrote:

 I have a simple


 **dub.sdl**
 ```
 name "test"
 targetType "executable"
 buildOptions "betterC"
 ```

 **app.d**
 ```
 module test;
 import core.stdc.stdio : fprintf, stderr;

 extern(C) int main(string[] args)
 {
 	fprintf(stderr, "Test\n",);
 	return 0;
 }
 ```



 When I'm trying to compile this on windows with latest dmd or 
 ldc I get
 ```Performing "debug" build using 
 C:\D\dmd2\windows\bin64\dmd.exe for x86_64.
 test ~master: building configuration "application"...
 Linking...
 test.obj : error LNK2019: unresolved external symbol stderr 
 referenced in function main
 .dub\build\application-debug-windows-x86_64-dmd_v2.098.1-dirty-FB5231E74956BBA34BF96
F450A8342C\test.exe : fatal error LNK1120: 1 unresolved externals
 Error: linker exited with status 1120
 C:\D\dmd2\windows\bin64\dmd.exe failed with exit code 1.
 ```


 Works with dmd-2.091.0

 Any idea what might be the problem here?


Yes, I have an idea, although not a Windows user. So look at the 
definitions i `core.stdc.stdio`:

```d
else version (CRuntime_Microsoft)
{
     ///
     shared FILE* stdin;  // = &__iob_func()[0];
     ///
     shared FILE* stdout; // = &__iob_func()[1];
     ///
     shared FILE* stderr; // = &__iob_func()[2];
}
```

shouldn't these variable declarations be `extern` ?



 Feb 01 2022



 next sibling parent reply Basile B. <b2.temp gmx.com>  writes:


On Wednesday, 2 February 2022 at 07:33:58 UTC, Basile B. wrote:

 On Wednesday, 2 February 2022 at 01:24:30 UTC, Abby wrote:

 I have a simple


 **dub.sdl**
 ```
 name "test"
 targetType "executable"
 buildOptions "betterC"
 ```


 shouldn't these variable declarations be `extern` ?


Try


```d
module test;
import core.stdc.stdio : FILE, fprintf;

extern shared FILE* stderr;

extern(C) int main(string[] args)
{
	fprintf(stderr, "Test\n",);
	return 0;
}
```

to confirm if it is or not the extern problem



 Feb 01 2022



 next sibling parent  forkit <forkit gmail.com>  writes:


On Wednesday, 2 February 2022 at 07:51:07 UTC, Basile B. wrote:

 extern shared FILE* stderr;


nope. won't even compile with -m32 now



 Feb 01 2022



prev sibling  parent reply duser <duser neet.fi>  writes:


On Wednesday, 2 February 2022 at 07:51:07 UTC, Basile B. wrote:

 On Wednesday, 2 February 2022 at 07:33:58 UTC, Basile B. wrote:

 On Wednesday, 2 February 2022 at 01:24:30 UTC, Abby wrote:

 I have a simple


 **dub.sdl**
 ```
 name "test"
 targetType "executable"
 buildOptions "betterC"
 ```


 shouldn't these variable declarations be `extern` ?


 Try


 ```d
 module test;
 import core.stdc.stdio : FILE, fprintf;

 extern shared FILE* stderr;

 extern(C) int main(string[] args)
 {
 	fprintf(stderr, "Test\n",);
 	return 0;
 }
 ```

 to confirm if it is or not the extern problem


missing `extern(C)`, it should be:

```D
module test;
import core.stdc.stdio : FILE, fprintf;

extern(C) extern shared FILE* stderr;

extern(C) int main(string[] args)
{
	fprintf(stderr, "Test\n",);
	return 0;
}
```



 Feb 02 2022



  parent reply forkit <forkit gmail.com>  writes:


On Wednesday, 2 February 2022 at 09:27:02 UTC, duser wrote:

 missing `extern(C)`, it should be:

 ```D
 module test;
 import core.stdc.stdio : FILE, fprintf;

 extern(C) extern shared FILE* stderr;

 extern(C) int main(string[] args)
 {
 	fprintf(stderr, "Test\n",);
 	return 0;
 }
 ```


pls.. not more 'extern's ... I'm seeing 'extern' everywhere now...

..I'm gunna puke if I see another one.

and no, that doesn't work either :-(



 Feb 02 2022



  parent reply bauss <jj_1337 live.dk>  writes:


On Wednesday, 2 February 2022 at 10:53:56 UTC, forkit wrote:

 On Wednesday, 2 February 2022 at 09:27:02 UTC, duser wrote:

 missing `extern(C)`, it should be:

 ```D
 module test;
 import core.stdc.stdio : FILE, fprintf;

 extern(C) extern shared FILE* stderr;

 extern(C) int main(string[] args)
 {
 	fprintf(stderr, "Test\n",);
 	return 0;
 }
 ```


 pls.. not more 'extern's ... I'm seeing 'extern' everywhere 
 now...

 ..I'm gunna puke if I see another one.

 and no, that doesn't work either :-(


extern(C) should imply extern in my book. I'm not sure if it 
does, but it seems wrong if it doesn't.



 Feb 02 2022



 next sibling parent  Tejas <notrealemail gmail.com>  writes:


On Wednesday, 2 February 2022 at 11:46:47 UTC, bauss wrote:

 On Wednesday, 2 February 2022 at 10:53:56 UTC, forkit wrote:

 On Wednesday, 2 February 2022 at 09:27:02 UTC, duser wrote:

 missing `extern(C)`, it should be:

 ```D
 module test;
 import core.stdc.stdio : FILE, fprintf;

 extern(C) extern shared FILE* stderr;

 extern(C) int main(string[] args)
 {
 	fprintf(stderr, "Test\n",);
 	return 0;
 }
 ```


 pls.. not more 'extern's ... I'm seeing 'extern' everywhere 
 now...

 ..I'm gunna puke if I see another one.

 and no, that doesn't work either :-(


 extern(C) should imply extern in my book. I'm not sure if it 
 does, but it seems wrong if it doesn't.


Shouldn't `extern` imply `extern(D)` for D?
In C, `extern` implies `extern "C"`
In C++, `extern` implies `extern "C++"`

Why different behaviour for D?



 Feb 02 2022



prev sibling  parent  Petar Kirov [ZombineDev] <petar.p.kirov gmail.com>  writes:


On Wednesday, 2 February 2022 at 11:46:47 UTC, bauss wrote:

 [..]

 extern(C) should imply extern in my book. I'm not sure if it 
 does, but it seems wrong if it doesn't.


No, there is a difference between **declaration** and 
**definition** at the linker level. `extern 
(C|C++|C|Objective-C|Windows|System)` sets the mangling of a 
variable declaration or definition. `extern` changes a variable 
definition to a declaration.

Check the following cases:


```d
import core.stdc.stdio : FILE, printf, fprintf;

shared FILE* stderr; // 1.
// extern (D) shared FILE* stderr; // 2.
// extern (C) shared FILE* stderr; // 3.
// extern shared FILE* stderr; // 4.
// extern extern (C) shared FILE* stderr; // 5.


pragma (msg, stderr.mangleof, "\n");

void main()
{
     if (stderr)
         fprintf(stderr, "stderr exists.\n");
     else
         printf("stderr doesn't exist.\n");
}
```

1. `shared FILE* stderr;` -> A global variable `stderr` 
**declared** and **defined** in the current module with D linkage
     * Compiles and links ok.
     * Prints `_D9onlineapp6stderrOPS4core4stdc5stdio8_IO_FILE` at 
compile-time.
     * Prints `stderr doesn't exist.` at run-time.
2. `extern (D) shared FILE* stderr;` -> Same as above - `extern 
(D)` is the default linkage.
3. `extern (C) shared FILE* stderr;` -> A global variable 
`stderr` **declared** and **defined** in the current module with 
C linkage
     * Compiles and links ok.
     * Prints `stderr` at compile-time.
     * Prints `stderr doesn't exist.` at run-time.
4. `extern shared FILE* stderr;` -> A global variable `stderr` 
**declared** but **not defined** in the current module with D 
linkage. It has to be defined in another module (library)
     * Compiles ok, but fails to link.
     * Prints `_D9onlineapp6stderrOPS4core4stdc5stdio8_IO_FILE` at 
compile-time.
     * Doesn't run
6. `extern extern (C) shared FILE* stderr;` -> A global variable 
`stderr` **declared** but **not defined** in the current module 
with C linkage. It has to be defined in another module (library)
     * Compiles and links ok (the compiler/linker driver 
automatically links libc).
     * Prints `stderr` at compile-time.
     * Prints `stderr exists.` at run-time.



 Feb 02 2022



prev sibling  parent reply kinke <noone nowhere.com>  writes:


On Wednesday, 2 February 2022 at 07:33:58 UTC, Basile B. wrote:

 ```d
 else version (CRuntime_Microsoft)
 {
     ///
     shared FILE* stdin;  // = &__iob_func()[0];
     ///
     shared FILE* stdout; // = &__iob_func()[1];
     ///
     shared FILE* stderr; // = &__iob_func()[2];
 }
 ```

 shouldn't these variable declarations be `extern` ?


Nope, they are macros in the MSVC headers, no symbols are 
available. That's why druntime defines them and sets them up at 
startup, so they aren't available/linked with `-betterC`.



 Feb 02 2022



 next sibling parent reply Abby <abby gmail.com>  writes:


On Wednesday, 2 February 2022 at 12:17:01 UTC, kinke wrote:

 On Wednesday, 2 February 2022 at 07:33:58 UTC, Basile B. wrote:

 ```d
 else version (CRuntime_Microsoft)
 {
     ///
     shared FILE* stdin;  // = &__iob_func()[0];
     ///
     shared FILE* stdout; // = &__iob_func()[1];
     ///
     shared FILE* stderr; // = &__iob_func()[2];
 }
 ```

 shouldn't these variable declarations be `extern` ?


 Nope, they are macros in the MSVC headers, no symbols are 
 available. That's why druntime defines them and sets them up at 
 startup, so they aren't available/linked with `-betterC`.


Thank you very much, do you know which lib should be linked and 
why it all works in dmd-2.091.0?



 Feb 02 2022



  parent  Steven Schveighoffer <schveiguy gmail.com>  writes:


On 2/2/22 8:16 AM, Abby wrote:

 On Wednesday, 2 February 2022 at 12:17:01 UTC, kinke wrote:

 On Wednesday, 2 February 2022 at 07:33:58 UTC, Basile B. wrote:

 ```d
 else version (CRuntime_Microsoft)
 {
     ///
     shared FILE* stdin;  // = &__iob_func()[0];
     ///
     shared FILE* stdout; // = &__iob_func()[1];
     ///
     shared FILE* stderr; // = &__iob_func()[2];
 }
 ```

 shouldn't these variable declarations be `extern` ?


 Nope, they are macros in the MSVC headers, no symbols are available. 
 That's why druntime defines them and sets them up at startup, so they 
 aren't available/linked with `-betterC`.


 
 Thank you very much, do you know which lib should be linked and why it 
 all works in dmd-2.091.0?


Well, looking at the blame for that file, those lines have been there 
for 10 years, so that isn't the reason for the change.

-Steve



 Feb 02 2022



prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com>  writes:


On 2/2/22 7:17 AM, kinke wrote:

 On Wednesday, 2 February 2022 at 07:33:58 UTC, Basile B. wrote:

 ```d
 else version (CRuntime_Microsoft)
 {
     ///
     shared FILE* stdin;  // = &__iob_func()[0];
     ///
     shared FILE* stdout; // = &__iob_func()[1];
     ///
     shared FILE* stderr; // = &__iob_func()[2];
 }
 ```

 shouldn't these variable declarations be `extern` ?


 
 Nope, they are macros in the MSVC headers, no symbols are available. 
 That's why druntime defines them and sets them up at startup, so they 
 aren't available/linked with `-betterC`.


I investigated the history of where these are set (in rt/msvc.d), and 
it's fascinating.

I'm not sure why it works on 2.091, though, this setup has existed since 
at least 2015, and probably before. See this PR: 
https://github.com/dlang/druntime/pull/1360

It was changed from a c file to a d file in October 2020 (see 
https://github.com/dlang/druntime/pull/3223), maybe that has something 
to do with it? Though it still shouldn't be running the init_msvc 
function in -betterC, even in 2.091 (which was released before this 
change). I tend to believe that maybe the OP is mistaken that it works, 
or there was a latent bug that was still running some of druntime that 
has been fixed.

-Steve



 Feb 02 2022



 next sibling parent reply Dennis <dkorpel gmail.com>  writes:


On Wednesday, 2 February 2022 at 14:38:49 UTC, Steven 
Schveighoffer wrote:

 I tend to believe that maybe the OP is mistaken that it works, 
 or there was a latent bug that was still running some of 
 druntime that has been fixed.


Maybe 2.091 was when dub still defaulted to OMF using the 
DigitalMars runtime, and it just seems to work since it's not 
using the Windows runtime.



 Feb 02 2022



  parent  Steven Schveighoffer <schveiguy gmail.com>  writes:


On 2/2/22 12:19 PM, Dennis wrote:

 On Wednesday, 2 February 2022 at 14:38:49 UTC, Steven Schveighoffer wrote:

 I tend to believe that maybe the OP is mistaken that it works, or 
 there was a latent bug that was still running some of druntime that 
 has been fixed.


 
 Maybe 2.091 was when dub still defaulted to OMF using the DigitalMars 
 runtime, and it just seems to work since it's not using the Windows 
 runtime.
 


I double checked. dub switched to MSCOFF by default [in 
2.086](https://dlang.org/changelog/2.086.0.html#dmd-mscoff-default).

Though it's possible the user is using a different version of dub.

Only way to be sure is to do a clean install and try it on Windows.

-Steve



 Feb 03 2022



prev sibling  parent reply forkit <forkit gmail.com>  writes:


On Wednesday, 2 February 2022 at 14:38:49 UTC, Steven 
Schveighoffer wrote:

 I'm not sure why it works on 2.091, though, this setup has 
 existed since at least 2015, and probably before. See this PR: 
 https://github.com/dlang/druntime/pull/1360


but it doesn't work on 2.091 ??

how this has escaped the testing process ..is..well..kinda 
disturbing.

This code below, will not compile using these parameters:

-m64 -betterC

but WILL using

-m32 -betterC

// ---

module test;

import core.stdc.stdio;

extern (C):

int main(int argc,char** argv)
{
     fprintf(stderr, "grr!\n");

     return 0;
}

// -----



 Feb 02 2022



  parent reply forkit <forkit gmail.com>  writes:


On Wednesday, 2 February 2022 at 18:51:04 UTC, forkit wrote:

 This code below, will not compile using these parameters:

 -m64 -betterC

 but WILL using

 -m32 -betterC


.. I mean specifically on Windows of course.

It's fine on linux.



 Feb 02 2022



 next sibling parent  forkit <forkit gmail.com>  writes:


On Wednesday, 2 February 2022 at 18:57:21 UTC, forkit wrote:


if only godbolt supported D on it's MSVC compilers :-(

https://www.godbolt.ms/



 Feb 02 2022



prev sibling  parent  Steven Schveighoffer <schveiguy gmail.com>  writes:


On 2/2/22 1:57 PM, forkit wrote:

 On Wednesday, 2 February 2022 at 18:51:04 UTC, forkit wrote:

 This code below, will not compile using these parameters:

 -m64 -betterC

 but WILL using

 -m32 -betterC


 
 .. I mean specifically on Windows of course.
 
 It's fine on linux.


Dennis is likely correct that it has to do with whether you are using 
MSVC libc or DMC libc.

I was going to look further, but github seems to be down.

-Steve



 Feb 02 2022



prev sibling  parent reply Walter Bright <newshound2 digitalmars.com>  writes:


On 2/2/2022 4:17 AM, kinke wrote:

 On Wednesday, 2 February 2022 at 07:33:58 UTC, Basile B. wrote:

 ```d
 else version (CRuntime_Microsoft)
 {
     ///
     shared FILE* stdin;  // = &__iob_func()[0];
     ///
     shared FILE* stdout; // = &__iob_func()[1];
     ///
     shared FILE* stderr; // = &__iob_func()[2];
 }
 ```

 shouldn't these variable declarations be `extern` ?


 
 Nope, they are macros in the MSVC headers, no symbols are available. That's
why 
 druntime defines them and sets them up at startup, so they aren't 
 available/linked with `-betterC`.


The trouble is -betterC does not link with druntime, so it can't find stderr. 
The solution is to make stderr a template, so that no linking with druntime is 
necessary.



 Feb 02 2022



  parent reply kinke <noone nowhere.com>  writes:


On Wednesday, 2 February 2022 at 20:58:25 UTC, Walter Bright 
wrote:

 On 2/2/2022 4:17 AM, kinke wrote:

 On Wednesday, 2 February 2022 at 07:33:58 UTC, Basile B. wrote:

 ```d
 else version (CRuntime_Microsoft)
 {
     ///
     shared FILE* stdin;  // = &__iob_func()[0];
     ///
     shared FILE* stdout; // = &__iob_func()[1];
     ///
     shared FILE* stderr; // = &__iob_func()[2];
 }
 ```

 shouldn't these variable declarations be `extern` ?


 
 Nope, they are macros in the MSVC headers, no symbols are 
 available. That's why druntime defines them and sets them up 
 at startup, so they aren't available/linked with `-betterC`.


 The trouble is -betterC does not link with druntime, so it 
 can't find stderr. The solution is to make stderr a template, 
 so that no linking with druntime is necessary.


That's not a solution, but a hack. ;) - With at least 2 major 
problems:

* Template culling. If the compiler e.g. sees a stderr 
instantiation in druntime in the import graph, it may decide not 
to emit the stderr symbol into the betterC binary, assuming that 
druntime will be linked anyway.
* Potentially a DSO-local stderr symbol for each binary 
(executable or DLL/.so/.dylib), so that changing it in one DSO 
might not change it for the whole process.

There have been previous 'dummy-templatizations' in 
druntime/Phobos to work around missing symbols with -betterC. 
IMO, that's just patching over the cracks of the -betterC hack 
and pessimizing regular D, and in case it's not obvious, I'm 
definitely no fan of this. :)



 Feb 03 2022



 next sibling parent reply Steven Schveighoffer <schveiguy gmail.com>  writes:


On 2/3/22 2:55 PM, kinke wrote:

 On Wednesday, 2 February 2022 at 20:58:25 UTC, Walter Bright wrote:

 On 2/2/2022 4:17 AM, kinke wrote:

 On Wednesday, 2 February 2022 at 07:33:58 UTC, Basile B. wrote:

 ```d
 else version (CRuntime_Microsoft)
 {
     ///
     shared FILE* stdin;  // = &__iob_func()[0];
     ///
     shared FILE* stdout; // = &__iob_func()[1];
     ///
     shared FILE* stderr; // = &__iob_func()[2];
 }
 ```

 shouldn't these variable declarations be `extern` ?


 Nope, they are macros in the MSVC headers, no symbols are available. 
 That's why druntime defines them and sets them up at startup, so they 
 aren't available/linked with `-betterC`.


 The trouble is -betterC does not link with druntime, so it can't find 
 stderr. The solution is to make stderr a template, so that no linking 
 with druntime is necessary.


 
 That's not a solution, but a hack. ;) - With at least 2 major problems:
 
 * Template culling. If the compiler e.g. sees a stderr instantiation in 
 druntime in the import graph, it may decide not to emit the stderr 
 symbol into the betterC binary, assuming that druntime will be linked 
 anyway.
 * Potentially a DSO-local stderr symbol for each binary (executable or 
 DLL/.so/.dylib), so that changing it in one DSO might not change it for 
 the whole process.
 
 There have been previous 'dummy-templatizations' in druntime/Phobos to 
 work around missing symbols with -betterC. IMO, that's just patching 
 over the cracks of the -betterC hack and pessimizing regular D, and in 
 case it's not obvious, I'm definitely no fan of this. :)


Since pragma inline works now even without the -inline switch, could an 
inline function take the place of the macro?

-Steve



 Feb 03 2022



  parent reply kinke <noone nowhere.com>  writes:


On Thursday, 3 February 2022 at 21:56:27 UTC, Steven 
Schveighoffer wrote:

 Since pragma inline works now even without the -inline switch, 
 could an inline function take the place of the macro?


Nope, sadly not - the problem is `&stderr` returning a function 
pointer then, not the address of the symbol directly.



 Feb 03 2022



  parent reply Steven Schveighoffer <schveiguy gmail.com>  writes:


On 2/3/22 5:13 PM, kinke wrote:

 On Thursday, 3 February 2022 at 21:56:27 UTC, Steven Schveighoffer wrote:

 Since pragma inline works now even without the -inline switch, could 
 an inline function take the place of the macro?


 
 Nope, sadly not - the problem is `&stderr` returning a function pointer 
 then, not the address of the symbol directly.


Ugh, yep. Damn us for not correctly implementing  property.

Would be the same problem with a template as well.

-Steve



 Feb 03 2022



 next sibling parent reply Tejas <notrealemail gmail.com>  writes:


On Friday, 4 February 2022 at 00:54:50 UTC, Steven Schveighoffer 
wrote:

 On 2/3/22 5:13 PM, kinke wrote:

 On Thursday, 3 February 2022 at 21:56:27 UTC, Steven 
 Schveighoffer wrote:

 Since pragma inline works now even without the -inline 
 switch, could an inline function take the place of the macro?


 
 Nope, sadly not - the problem is `&stderr` returning a 
 function pointer then, not the address of the symbol directly.


 Ugh, yep. Damn us for not correctly implementing  property.

 Would be the same problem with a template as well.

 -Steve


What will it take to implement ` property` correctly? What is it 
that we're lacking?

I genuinely don't understand anything about this particular 
topic: what is preventing us from fixing this particular part of 
the language even though it crops up pretty frequently?
Could you maybe please link me to a forum post where this has 
been discussed?



 Feb 03 2022



  parent  Steven Schveighoffer <schveiguy gmail.com>  writes:


On 2/3/22 11:13 PM, Tejas wrote:

 On Friday, 4 February 2022 at 00:54:50 UTC, Steven Schveighoffer wrote:

 Ugh, yep. Damn us for not correctly implementing  property.

 Would be the same problem with a template as well.


 
 What will it take to implement ` property` correctly? What is it that 
 we're lacking?


What  property *should* have done (it's very limited in functionality 
now, and not likely to be fixed) is to disable accessing via the 
function at all. The fact that it's a function call should be an 
implementation detail.

in other words:

```d
int _x;
 property ref int x() { return _x;}


static assert(is(typeof(x) == int)); // this is true today
static assert(typeof(&x) == int *)); // this is not true but should be

auto y = x(); // should not compile, but does, an int is not a function.
```

If this were the case, then fixing the stderr problem mentioned here 
would be possible using properties.


 I genuinely don't understand anything about this particular topic: what 
 is preventing us from fixing this particular part of the language even 
 though it crops up pretty frequently?
 Could you maybe please link me to a forum post where this has been 
 discussed?


The  property debate is really old. When it was added, the thought was 
to get rid of some of these sticky corner cases. D has had property 
*syntax* since D1. But the  property attribute was supposed to be a way 
to declare "this is a property, so it shouldn't behave like a function".

But core members disliked the added complications, and so the benefits 
of  property were kind of cancelled. There are a few draft DIPS on it 
(from the old system in the wiki, see here: 
https://wiki.dlang.org/DIPs). Now we are just left with a really obscure 
difference (the typeof difference) which is IMO confusing anyway.

-Steve



 Feb 04 2022



prev sibling  parent  Steven Schveighoffer <schveiguy gmail.com>  writes:


On 2/3/22 7:54 PM, Steven Schveighoffer wrote:

 On 2/3/22 5:13 PM, kinke wrote:

 On Thursday, 3 February 2022 at 21:56:27 UTC, Steven Schveighoffer wrote:

 Since pragma inline works now even without the -inline switch, could 
 an inline function take the place of the macro?


 Nope, sadly not - the problem is `&stderr` returning a function 
 pointer then, not the address of the symbol directly.


 
 Ugh, yep. Damn us for not correctly implementing  property.
 
 Would be the same problem with a template as well.


Was going to post about this on Rainer's PR to fix this issue, but as it 
turns out, none of this matters -- on Windows, `stderr` is a constant, 
and in fact the return value from a function.

So `&stderr` isn't valid, and the fact that it currently works is not 
actually correct. In fact, in D currently you can set `stderr` to 
something else, and it won't apply to the C side, which is really bad.

And as a template function, `&stderr` is a compiler error anyway.

-Steve



 Feb 12 2022



prev sibling  parent  Walter Bright <newshound2 digitalmars.com>  writes:


On 2/3/2022 11:55 AM, kinke wrote:

 * Template culling. If the compiler e.g. sees a stderr instantiation in
druntime 
 in the import graph, it may decide not to emit the stderr symbol into the 
 betterC binary, assuming that druntime will be linked anyway.
 * Potentially a DSO-local stderr symbol for each binary (executable or 
 DLL/.so/.dylib), so that changing it in one DSO might not change it for the 
 whole process.
 
 There have been previous 'dummy-templatizations' in druntime/Phobos to work 
 around missing symbols with -betterC. IMO, that's just patching over the
cracks 
 of the -betterC hack and pessimizing regular D, and in case it's not obvious, 
 I'm definitely no fan of this. :)


"Header only" libraries work well for C++. We can make it work for D. In fact, 
we have to.

As for stderr, it should never be an instance of the iob itself. That instance 
resides only in the C stdlib. stderr should only be an indirect reference to
it, 
hence multiple instances of stderr should work just fine.

With a bit of careful library design, we can make this work.



 Feb 03 2022