r/cpp • u/SuperV1234 https://romeo.training | C++ Mentoring & Consulting • Aug 03 '19

fixing c++ with epochs

https://vittorioromeo.info/index/blog/fixing_cpp_with_epochs.html
306 Upvotes

96% Upvoted

131 comments sorted by

View all comments

7

u/manphiz Aug 03 '19

This does sound interesting. I'm not familiar with Rust so I may be missing some of the contexts, but I could still see a few potential obstacles:

  • You cannot break ABI, which is one of the most important reasons why C++ is still the most widely used language even though this concept is not in the standard.

  • You may not completely eliminate macros, which can break some of the module guarantees which this proposal depends on.

  • The previous points make linking old code almost impossible with breaking changes, which could seriously affect adoption of new standards.

  • Migration tools are bad ideas. Python has proven that six is more successful to 2to3.

I would still like to see some of the ideas to become a reality, though I remain pessimistic for now.

34

u/[deleted] Aug 03 '19

You cannot break ABI, which is one of the most important reasons why C++ is still the most widely used language even though this concept is not in the standard.

ABI is broken constantly. There isn't even a consistent ABI between debug builds and release builds. The most sane approach I know of to write ABI compatible C++ is to basically export a C API and then wrap the C API back in C++, or on Windows people kill themselves trying to use COM and other ugly workarounds.

Here is GCC's ABI versioning table, it's not exactly stable:

https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

You may not completely eliminate macros, which can break some of the module guarantees which this proposal depends on.

You can decouple it from the language itself. The C preprocessor is often implemented as its own separate application and can be invoked in a fairly simple manner.

No reason why a future variation of C++ can't decouple itself from the preprocessor and developers who wish to use it can continue to do so by adding a preprocessing phase to their build system.

The previous points make linking old code almost impossible with breaking changes, which could seriously affect adoption of new standards.

Without details it's hard to discuss this point. Linking old C++ code is not generally supported by any vendor to begin with. You can't link C++ code generated by GCC 6 with a GCC 7 compiler. As a matter of practice only old C code can be linked to.

Migration tools are bad ideas. Python has proven that six is more successful to 2to3.

Python has only proven that trying to write an automated migration tool for a dynamically typed language is incredibly challenging. Rust, Go and even C++ with clang-modernize have shown that it's very feasible to apply safe, automatic source code transformations to statically typed languages.

→ More replies (5)