C++ is terrible

gistfile1.irclog

[20:36:38] <larryv> geekosaur: oy, all this is giving me a headache
[20:38:13] <geekosaur> yes
[20:45:29] <geekosaur> hopefully my latest reply clarifies the actual issue
[20:50:03] <geekosaur> (implied but not stated, btw: C++11 broke *everyone's* existing C++ runtime API/ABI)
[20:53:41] <larryv> haha
[20:53:58] <larryv> yes, it's much clearer now, thanks
[20:54:45] <geekosaur> also it is bnoth API and ABI because they need bit level compatibility for objects compiled with one C++ compiler to work with objects compiled by a different one; API alone is insufficient
[20:58:12] <larryv> is that mitigated if both standard libraries use the same low level support?
[20:58:30] <larryv> i.e., libstdc++ on OS X using libc++abi
[20:58:35] <larryv> or libc++ on Linux using libsupc++
[21:00:14] <geekosaur> because of licensing conflicts clang's libc++ cannot provide libstdc++'s pre-C++11 support unless someone does the work to clean-room an ABI compatible version of libstdc++ pre-C++11
[21:00:56] <geekosaur> in the other direction, if you for some reason need to mix stuff written to Apple libstdc++ with C++11 objects, you are forced to build your own private copy of a C++11-supporting (hence GPL3) libstdc++
[21:01:31] <geekosaur> licenses doth make fools of us all, yet again...
[21:03:14] <geekosaur> and if anyone out there was using a pre-C++11 clang (is there one?) then they're just as screwed now as they were before >.>
[21:03:31] <larryv> haha
[21:05:00] <geekosaur> (since they needed their own runtime and could not use Apple's; in theory on Mavericks they could now use the system one *if* it happens to provide pre-C++11 support. I would not be surprised if Apple left it out)
[21:05:47] <geekosaur> it's also not clear that you could reasonably provide such a compatibility ABI, if g++'s pre-C++11 ABI was different enough
[21:06:02] <larryv> i assume by "pre-C++11 support" you mean any ABI or API details that were changed for C++11
[21:07:11] <larryv> sorry if that's a dumb question, there's a lot to wrap my head around
[21:07:44] <geekosaur> every compiler had its own internals with approximately zero compatibility
[21:08:14] <geekosaur> C++11 changed this because you couldn't mix C++ objects built with one compiler with C++ objects built with another.
[21:08:21] <larryv> right
[21:08:40] <larryv> so if you have code that depends on the pre-C++11 behavior
[21:08:55] <larryv> that won't work with C++11-compatible compilers/stdlibs
[21:09:00] <larryv> ?
[21:09:08] <geekosaur> so, the big ABI break was C++11. before that, only way to do it was use the same compiler everywhere. after, you must use C++11 everywhere, backward compat is not guaranteed even for the same compiler (but the LGPL3 libstdC++ I think does provide at least some backward compat)
[21:09:37] <geekosaur> it can generally be recompiled with a C++11 compliant compiler. existing objects generally won't work
[21:10:38] <geekosaur> the API details tend to be hidden in the implementation of STL and in the support code generated by the compiler; not in the source code, aside from C++11 language features which are generally not backward incompatible
[21:11:10] <geekosaur> so you should always be able to compile older code with a newer compiler. you just can't mix object code generated by pre-C++11
[21:12:56] <geekosaur> but that's where older systems lose hard because any system level libraries with C++ code in them were built with a pre-C++11 compiler
[21:13:26] <larryv> ahh
[21:14:25] <geekosaur> (so for example objc++ or apple's c++ frameworks)
[21:14:45] <larryv> right
[21:15:01] <larryv> so is --std=c++11 only relevant for language features
[21:15:07] <geekosaur> yes
[21:15:15] <geekosaur> the runtime is the same regardless
[21:15:18] <larryv> alright that was confusing
[21:15:23] <larryv> so even if you compile vanilla C++
[21:15:27] <larryv> you get C++11 object code
[21:15:51] <geekosaur> and I suspect that the only real solution is for someone to clean-room libstdc++'s pre-C++11 runtime support so that it can be added to libc++
[21:16:25] <geekosaur> yep
[21:17:24] <larryv> as for mixing C++11 stdlibs
[21:17:32] <larryv> does that require that they share low level support
[21:17:40] <geekosaur> that should always be safe, since it's the reason C++11 defined an ABI
[21:18:12] <geekosaur> the mixing-objects-from-different-compilers problem was completely intractable without a predefined ABI
[21:18:16] <larryv> hm
[21:18:21] <geekosaur> so C++11 accepted the need and defined the ABI
[21:18:59] <geekosaur> (sort of. they said what was needed and left the compiler designers for each platform to sort out the details, but C++11 compatibility requires going along with the platform specific ABI)
[21:19:10] <larryv> even if you have multiple identical runtimes in the same address space?
[21:19:30] <geekosaur> you wouldn't; you'd have only the one. loading a different one gets you all sorts of errors
[21:19:52] <geekosaur> but the point of this is you don't do that, you have one runtime on the platform and everything uses it
[21:20:01] <larryv> right, but we sort of had that problem when each gcc had its own libsupc++
[21:20:12] <geekosaur> yes, that was the pre-C++11 issue
[21:20:35] <geekosaur> gcc changed theirs with every compiler version for a long time (I think this ended sometime in the 3.x series)
[21:20:53] <larryv> hm
[21:21:33] <geekosaur> libstdc++ was part of gcc recognizing this issue between their compiler versions and freezing the ABI so you could mix compiler versions. C++11 extends this to all compilers, not just gcc
[21:22:04] <larryv> but you'd still need just the one libstdc++, right
[21:22:07] <geekosaur> right
[21:22:14] <larryv> okay that was the problem i meant
[21:22:23] <larryv> when each gcc4x port had its own libstdc++
[21:23:08] <geekosaur> my previous job, one of the things I did was support gcc and manage our (multiple) installs. I become all too familiar with this issue
[21:23:25] <larryv> that explains a lot :)
[21:23:26] <geekosaur> in its "objects from different gcc-s were not interoperable" version
[21:23:33] <geekosaur> *became
[21:24:10] <larryv> on Linux it seems you can compile libc++ using libsupc++ rather than libc++abi
[21:24:14] <geekosaur> and that was back when you couldn't just pick one gcc support library and use it everywhere because the compilers all produced code for their specific support library
[21:24:24] <larryv> is that required to mix objects build against libc++ with objects built against libstdc++
[21:24:43] <geekosaur> in the pre-c++11 case, yes
[21:25:02] <geekosaur> (that is, for objects built with pre-c++11 compilers)
[21:25:20] <larryv> huh
[21:25:47] <larryv> so if you have all C++11 objects, it's okay if some of them use libc++abi and others use libsupc++?
[21:26:12] <larryv> i thought you needed a single runtime
[21:26:12] <geekosaur> yes
[21:26:24] <geekosaur> because the runtimes are ABI compatible, so you can use either as the runtime
[21:26:47] <geekosaur> there can be API differences at compile time (usually hidden in the STL) as long as the runtimes are compatible
[21:26:50] <larryv> right, but can you use both at once?
[21:26:55] <larryv> in one process space?
[21:27:11] <geekosaur> which requires some trickery but they've done that on Linux, so that at runtime they use the same runtime, whichever one it is
[21:27:34] <larryv> i guess i'm trying to distinguish between
[21:27:39] <larryv> being able to choose one or the other
[21:27:40] <larryv> and
[21:27:47] <larryv> using both simultaneously
[21:28:00] <geekosaur> usually though this would only come up with objects using the older ABI, and which library you use as the runtime defines what pre-C++11 support is "lifted" to C++11's runtime ABI
[21:28:20] <geekosaur> and if you try to mix pre-C++11 ABIs then you get the same mess we're facing now
[21:29:16] <geekosaur> it's fairly tangled, it's not surprising that you're confused and I admit to not knowing all the hairy details (and, quite honestly, being happier that way :)
[21:29:27] <larryv> hahaha
[21:30:47] <geekosaur> I think if you really want to know all the details, you should try talking to e.g. one of the debian gcc support folks
[21:31:13] <larryv> that wouldn't be a bad idea
[21:31:23] <geekosaur> C++ templates add a lot of complexity to the whole thing, leading to the otherwise rare case that different APIs can lead to the same ABI
[21:31:48] <geekosaur> which is where some of that libsupc++ stuff comes from, as I understand it
[21:32:28] <geekosaur> (basically the differences are all in the compile time support not the runtime, at this point, in order to deal with source level backward compatibility for folks playing evil games with template expansion)
[21:32:47] <larryv> ugh
[21:32:49] <larryv> lol
[21:33:07] <geekosaur> (some of which evil games are, well, kinda required by C++ at all. templates are the hairiest mess I've ever seen in programming)
[21:36:23] * geekosaur is remembering early g++ where they thought templates were easy and then discovered the hard way that you had to defer some of the code generation to link time the way they were doing it, or they'd getduplicate symbols from template stuff expanding in 50 different source files and generating the same symbols --- that had to be global so objects involving templates could be passed around
[21:37:23] <larryv> X(
[21:37:41] <larryv> a veritable basket of sunshine