Comment by josephg | Hacker News Reader

Comment by josephg | Hacker News Reader

Parent Full thread

Yes, I wonder that too. The comment says that debug and release builds have ABIs because they have different type layouts. But why do they have different type layouts? Bounds checking and assertions shouldn’t change the type layout. It seems to me that debug flags should generally only modify code generation & asserts. This is usually the case on Linux, and it’s extremely convenient.

If windows is going to insist on different libraries in debug and release mode, I wish the development version of the library bundled debug and release builds together so I could just say “link with library X” and the compiler, linker and runtime would just figure it out. (Like framework bundles on the Mac). Windows could start by having a standard for library file naming - foo.obj/dll for release and foo-debug.obj/dll for debug builds or something. Then make the compiler smart enough to pick the right file automatically.

Seriously. It’s 2024. We know how to make good compiler tooling (look at go, Swift, rust, etc). There’s no sane reason that C++ has to be so unbelievably complex and horrible to work with.

Windows debug builds add extra sanity checks for which it needs extra members in types. For instance, a vector<T>::iterator is just a T* in a regular build, but in a debug build it also keeps a pointer to the vector so it can check bounds on every access.

But yes, C++ punts a lot of things to the build system, partly because the standard has to work on embedded systems where shared libraries don’t exist. A better build system could fix most of these things, but every build system that tries ends up massively complicated and slow, like Bazel.

But fixing it in Windows doesn’t mean they also need to fix it in embedded systems. Microsoft is in control of their whole ecosystem from the kernel to userland to visual studio. Microsoft could make C++ on windows sane without anyone else’s permission. Their failure to do that is on them and them alone.

I think browser vendors have the right idea when it comes to evolving standards. Vendors experiment using their own products and then come together and try and standardise their work at committee. I think that would be a much better idea than either doing nothing or, as you say, trying to boil the ocean.

> Microsoft could make C++ on windows sane without anyone else’s permission.

C++ on Windows is perfectly OK, especially if you're building on Windows for Windows using MSVC or Clang-cl.

> Bounds checking and assertions shouldn’t change the type layout.

Any bounds checks and assertions that rely on storing additional data such as valid iterator ranges or mutation counters would need to change the type layout, wouldn't they?

Even if the STL were purely a header-only library (and influenced only by code generation changes for debug builds), there's still the problem of ABI compatibility across different translation units--or different libraries--which might be built with different options.

EDIT: One of your sibling comments goes into greater detail!

> I wish the development version of the library bundled debug and release builds together

Almost all do. Look for binary library releases; they almost always supply Debug and Release binaries together.

> Windows could start by having a standard for library file naming - foo.obj/dll for release and foo-debug.obj/dll for debug builds or something.

Funnily enough, it does. foo.lib for Release; food.lib for Debug.

Reply on news.ycombinator.com