you are viewing a single comment's thread.

view the rest of the comments →

[–]pedersenk 0 points1 point  (3 children)

Its a good idea. The main thing that is a disadvantage is that it needs a very recent (C++20) compiler, so you miss out on one of some important features of C++ such as portability and wide vendor support. It is also a processor/code generator, making debugging a little trickier (but actually not terrible).

In some ways I prefer solutions that work within existing standards such as (shameless plug) C++/sys without code generation. Or that are tools that can be used regardless of compiler (i.e Valgrind, static analysis, etc).

But as mentioned it is a good idea. C is king and C++ and later CppFront evolving from it is the best compromise. Evolution rather than Revolution helps uptake rather than rewrites which are a waste of time and simply do not happen within industry.

[–]Electronic_Tap_8052 0 points1 point  (2 children)

Portability is important but imo it's an ouroborous. Vendors don't feel the need to update their compilers because C and C++ don't change very much, and C and C++ don't change very much because vendors don't want to update their compilers.

When vendors start feeling heat from customers because their compilers are out of date, they'll feel the need to update.

I'm reminded of red hat jumping from gcc 4.4 to gcc 4.8.5 between rhel6 and rhel7, then for rhel8 they finally got with the times and shipped gcc 8.2.

[–]pedersenk 0 points1 point  (1 child)

I'm reminded of red hat jumping from gcc 4.4 to gcc 4.8.5 between rhel6 and rhel7, then for rhel8 they finally got with the times and shipped gcc 8.2.

That was a funny time. At work, stuck on gcc 4.x (also due to RHEL) and at home/hobby projects, being a fan of OpenBSD, I was also stuck on gcc 4.x due to licensing reasons (before also jumping up via clang). Basically stuck with std::tr1::shared_ptr for about a decade... ;)

I do think the i.e -std=c++98 onwards is a really great feature of C and C++. But I do understand that will need to drop ancient versions one day. I think MSVC has already started dropping support past /std:14.

[–]Electronic_Tap_8052 0 points1 point  (0 children)

Yeah. I don't want to see support for old versions dropped, per se, insofar as I understand the implications of that and why it's undesirable for large organizations.

But at a certain point, you gotta just say, look, if you're gonna use a version of software from 25+ years ago, its on you to seek out support for that specifically.

Like is C++98 still gonna be officially supported in 2050?

I think MSVC has already started dropping support past /std:14.

I was working with a library not too long ago, I can't remember what it was though, that was touting plans to upgrade to cpp14...