As far as I understand it is a wide-spread opinion within the C++ community that
ID: 652483 • Letter: A
Question
As far as I understand it is a wide-spread opinion within the C++ community that certain features of C++ (including some features inherited directly from C), while still usable in themselves, do not fit well with the most recent C++ best practices. For example, I read a comment on this site stating that new / delete should be avoided altogether in favor of smart pointers.
In view of this, I often wonder why backward compatibility with C and earlier C++ features is still important: to my knowledge there is no 100% compatibility, but most of C and C++ are contained in C++11 as a subset.
So, maybe it would be possible / make sense to drop earlier C++ features (e.g. the mentioned new / delete) from a future C++ standard so that it is impossible to use them in new code.
Existing code could still be maintained using the appropriate compiler. Interoperability between legacy and new code would be supported through separate compilation. One could continue to use the earlier standard or adopt the more recent one, only mixing the two would not be possible: a developer /team would have to clearly choose which programming style they want to use. The most flexible solution would be to have compiler options to switch on and off certain features (e.g. no new / delete allowed).
Would this be a viable strategy for encouraging the adoption of modern C++ practices? Are there technical problems (e.g. compiling existing templates, ABI compatibility) that make such a change too difficult or even impossible?
Explanation / Answer
If I understand correctly your position (from the question and the comments under VJovic's answer), you'd have preferred instead of a mostly compatible C++11, a new language based (I'll call it NC++) on C++03 but source incompatible with it but linkable with it.
Here are some points to consider:
it isn't possible to implement C++11 using existing C++03 ABI (compilers providers don't guarantee that linking code compiled in C++03 mode and in C++11 will works), and it is a safe guess that it would be the same for NC++. So you'd have to have new C++03 compilers targeting the NC++ ABI as well as NC++ compiler to have your idea implemented.
you have the same problem with the standard library. You'd need a new implementation of the C++03 library able to be interoperable with your NC++ library.
the transition from C to C++ can be smooth as C is mostly a C++ subset. When the C code takes advantage of C99 features not present in C++, the transition is less smooth. Notably shared headers have to be coded in the common subset of C++ and C which isn't natural if you want to take advantage of C99. In your case, shared headers will have to be coded in the common subset of C++03 and NC++, which I fear will be impractical if your goal in NC++ is to take advantage of the possibility to break source code compatibility to have a "cleaner" language.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.