Modern C++ Lamentations

[Rubn]

On Wednesday, 2 January 2019 at 02:04:24 UTC, Jonathan M Davis 
wrote:
> I'm by no means against having shared libraries in general 
> work, and I think that full dll support should exist for D on 
> Windows, but aside from plugins, in the vast majority of cases, 
> I think that using shared libraries is far more trouble than 
> it's worth (especially with how difficult it is to maintain ABI 
> compatibility with D libraries).

You've obviously haven't used shared libraries that much then -- 
that is shared libraries that link statically to the runtime. 
Having multiple instances of Phobos/druntime loaded at the same 
time in one process has it's own can of warms. I'm not surprised 
at all that in general people don't even use shared libraries.

>> > The whole nonsense where you have to rebuild your program, 
>> > because _anything_ changed in the dll is just ridiculous 
>> > IMHO.
>>
>> What?! Where did you hear this non-sense from? I'm not 
>> surprised at the state of shared library support on windows 
>> anymore.
>
>>From working with dlls with C++. With dlls on Windows, your 
>>program links
> against a static library associated with the dynamic library, 
> and if any of the symbols are changed, the addresses change, 
> and your program will be unable to load the newer version of 
> the library without being rebuilt against the new version of 
> the static library. This is in stark contrast to *nix where the 
> linking works in such a way that as long as the symbols still 
> exist with the same ABI in the newly built library, they're 
> found when the program loads, and it's not a problem. The 
> addresses aren't hard-coded in the way that happens with dlls 
> on Windows. dlls on Windows allow you to share code so long as 
> the programs are all built against exactly the same version of 
> the dll (and if they're not, then you need separate copies of 
> the dll, and you get into dll hell), whereas with *nix, you can 
> keep updating the shared library as much as you like without 
> changing the executable as long as the API and ABI of the 
> existing symbols don't change.
>
> - Jonathan M Davis


On Wednesday, 2 January 2019 at 04:09:29 UTC, H. S. Teoh wrote:
> On Tue, Jan 01, 2019 at 07:04:24PM -0700, Jonathan M Davis via 
> Digitalmars-d wrote: [...]
>> From working with dlls with C++. With dlls on Windows, your 
>> program links against a static library associated with the 
>> dynamic library, and if any of the symbols are changed, the 
>> addresses change, and your program will be unable to load the 
>> newer version of the library without being rebuilt against the 
>> new version of the static library.
>
> Wow. That makes me glad I'm not programming on Windows...

Mother of god, these two comments. Rip D on Windows, there's 
clearly only one competent Windows user on the D development 
team. It's too bad most of his work is focused on maintaining the 
VS plugin but from the looks of it if he didn't no one would. 
Everyone else is obliviously tucking incompetent.

If it worked the way you think it does (it doesn't) then every 
Windows update would literally break EVERY SINGLE executable file 
on the face of the earth. They would all need to be recompiled as 
the system DLL libraries are updated. You can only link to the 
system libraries dynamically virtually and every executable uses 
them. Yet somehow Windows is able to maintain backwards 
compatibility with old executable files better than Linux does. 
The more worrying thing about this is even though you said it 
yourself you barely use Windows yourself, rather than spending 
the 5 mins it would take for you to google search this yourself, 
you continue to go on with your misinformation that might have 
been true with Windows DOS 40 years ago. God damn.