3 ms·
People want to use new features in existing files without having to translate the whole file in one go. And they expect to link seamlessly the existing files ag
by gpderetta 3y ago
People want to use new features in existing files without having to translate the whole file in one go. And they expect to link seamlessly the existing files against new files.
If you throw enough tooling at the problem, it could probably be done. But it took 10 years to ship C++11 as is...
- ReleaseCandidat 3y ago> People want to use new features in existing files Yes, and it would have been The Right Thing(TM) to ignore these people. > And they expect to link seamlessly the existing files against new files. As I said, that shouldn't have been a problem (and it would have been a good time to talk about C++'s ABI). It's possible with C from C++ and there are actually other languages using even other compilers or interpreters or VMs that can use C++. And ignoring the problems when calling a C++ library compiled by another C++ compiler on Windows.
- spacechild1 3y ago> Yes, and it would have been The Right Thing(TM) to ignore these people. No, it wouldn't because it would have seriously hindered C++11 adoption. I have personally worked on an open source C++ project that had been originally written in C++98, but switched to "modern C++" for certain features (most notably, <thread> and <atomic>). It would have been a major pain if we had to rewrite all of our source code to remove incompatibilities, just so that we could use these new features in a few places. I cannot even imagine what it would be like in a large commercial code base. > As I said, that shouldn't have been a problem (and it would have been a good time to talk about C++'s ABI). It's possible with C from C++ Well, you could link, but you wouldn't be able to (safely) share any non-POD objects between compilation units because of possible ABI mismatches. That's not particularly useful. The problem is much more complex than you apparently think.