3 ms·

That's what I wanted to express: there would be no need to be able to use the old source code together with new code in the same file if they would have gotten

That's what I wanted to express: there would be no need to be able to use the old source code together with new code in the same file if they would have gotten rid of include files (and using modules instead). It would have been enough (see Fortran for example) to be able to use C++98 libraries and compile them with the same compiler (every C++ compiler I know of is a C Compiler too).

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.
Asooka 3y ago
The biggest lesson for me is that you need to provide an incremental path to using the new features. The reason C++ succeeded as much as it did is because you can incrementally C++-ify your existing C code. You can provide C interfaces to your new C++ stuff and you can use C interfaces from C++. Any new feature that you add to C++ has to offer such a path. That is why move semantics were very successful - you could add them incrementally and you could put a preprocessor guard around their definition so your library could be used by code written for both older and newer C++. In contrast, it is hard to incrementally module-ify. You can't transform half of your library to a module and I haven't seen a good story on how to offer a library as both a module and as traditional headers. So it's hard to adopt modules in an existing codebase, thus it's hard to get good feedback on them, thus modules took a long time to really iron out. Offering a path to incremental improvement is very important for large projects where features and bugfixes happen constantly. We can't stop our regular work to untangle the whole carefully built system of dependencies. The new features have to be offered in a form where we can use them in new code, while remaining compatible with old code and gradually add them to it as time permits.

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.

Asooka 3y ago

The biggest lesson for me is that you need to provide an incremental path to using the new features. The reason C++ succeeded as much as it did is because you can incrementally C++-ify your existing C code. You can provide C interfaces to your new C++ stuff and you can use C interfaces from C++. Any new feature that you add to C++ has to offer such a path. That is why move semantics were very successful - you could add them incrementally and you could put a preprocessor guard around their definition so your library could be used by code written for both older and newer C++. In contrast, it is hard to incrementally module-ify. You can't transform half of your library to a module and I haven't seen a good story on how to offer a library as both a module and as traditional headers. So it's hard to adopt modules in an existing codebase, thus it's hard to get good feedback on them, thus modules took a long time to really iron out. Offering a path to incremental improvement is very important for large projects where features and bugfixes happen constantly. We can't stop our regular work to untangle the whole carefully built system of dependencies. The new features have to be offered in a form where we can use them in new code, while remaining compatible with old code and gradually add them to it as time permits.