4 ms·

I watched the video on C++ ABI. It's really awful to hold back a language because a few companies cannot deal with it. C++ should really start to deprecate th

by jokoon 5y ago

I watched the video on C++ ABI. It's really awful to hold back a language because a few companies cannot deal with it. C++ should really start to deprecate thing, and reduce backward compatibility. Not to mention there are probably a few ways to use old code and to wrap it. It sort of boggles my mind how new C++ versions were able to maintain backward compatibility. Compilers must have a hard time doing it. That's why I think C++ should be forked... Not to mention microsoft is probably the main culprit here.

gpderetta 5y ago
On the contrary Microsoft has happily broken the C++ ABI early and often with MSVC for a very long time. They started to guarantee more stability recently because users demanded it. In fact GCC (and indirectly Red Hat and the other Linux distros), have been the most vocal for not breaking the ABI as many still have the scars of past ABI breaks .
- int_19h 5y ago
  Part of it is that dynamic linking and globally shared libraries have been a norm on Linux for so long. On Windows, it is still more common to either statically link the stdlib or install it side by side.
  - pjmlp 5y ago
    Dynamic linking has a been a thing on Windows since Windows 16 bit days, and is central to COM, static libraries are seldom used. The big difference to UNIX shared objects (with exception of Aix), is that Windows dynamic libraries are namespaced and symbols are private by default. That makes huge difference.
    - int_19h 5y ago
      Dynamic linking is there, yes. But the only globally shared libraries tend to be the OS ones - everything else, even the CRT (before it also became part of the OS), is normally installed side by side with the .exe, and every app has its own copy. Thus C++ ABI compatibility was not really an issue, except when you had to use closed-source C++ libraries. Yes, the other big difference is that every DLL has its own namespace, so you can actually load two CRTs into the same process just fine - so long as you don't pass pointers/handles from one runtime to the other. But this kind of multi-runtime arrangement doesn't happen often in practice, except in plugin/extension scenarios (where different extensions might bring in different runtimes into the same process).
      - pjmlp 5y ago
        COM libraries aren't usually side by side, and they are used a lot. Even if they aren't installed on System32 (thankfully), they get their own slot under Programs. Most applications that do xcopy installs tend to be .NET based.
        int_19h 5y ago
        These days, most COM libraries that aren't OS APIs are also installed side by side with the app, with information necessary for activation provided in .manifest - this feature has existed since WinXP. Although I would also say that third-party COM libraries are just not particularly common anymore.

by jokoon 5y ago

gpderetta 5y ago

On the contrary Microsoft has happily broken the C++ ABI early and often with MSVC for a very long time. They started to guarantee more stability recently because users demanded it. In fact GCC (and indirectly Red Hat and the other Linux distros), have been the most vocal for not breaking the ABI as many still have the scars of past ABI breaks .

int_19h 5y ago
Part of it is that dynamic linking and globally shared libraries have been a norm on Linux for so long. On Windows, it is still more common to either statically link the stdlib or install it side by side.
- pjmlp 5y ago
  Dynamic linking has a been a thing on Windows since Windows 16 bit days, and is central to COM, static libraries are seldom used. The big difference to UNIX shared objects (with exception of Aix), is that Windows dynamic libraries are namespaced and symbols are private by default. That makes huge difference.
  - int_19h 5y ago
    Dynamic linking is there, yes. But the only globally shared libraries tend to be the OS ones - everything else, even the CRT (before it also became part of the OS), is normally installed side by side with the .exe, and every app has its own copy. Thus C++ ABI compatibility was not really an issue, except when you had to use closed-source C++ libraries. Yes, the other big difference is that every DLL has its own namespace, so you can actually load two CRTs into the same process just fine - so long as you don't pass pointers/handles from one runtime to the other. But this kind of multi-runtime arrangement doesn't happen often in practice, except in plugin/extension scenarios (where different extensions might bring in different runtimes into the same process).
    - pjmlp 5y ago
      COM libraries aren't usually side by side, and they are used a lot. Even if they aren't installed on System32 (thankfully), they get their own slot under Programs. Most applications that do xcopy installs tend to be .NET based.
      - int_19h 5y ago
        These days, most COM libraries that aren't OS APIs are also installed side by side with the app, with information necessary for activation provided in .manifest - this feature has existed since WinXP. Although I would also say that third-party COM libraries are just not particularly common anymore.