Item — HN Reader

> I find it hard to justify starting a new projet using C++ today when there is languages like Rust, swift and golang to a lesser extent.

A simple reason, for Swift and Rust at least, if you want that your code from today to work without changes in 10 years from now you will use C++.

3 comments

I'm not sure C++ is more stable than Rust. It's pretty stable but it does introduce breaking changes and code written 10 years ago will not compile as C++11 without changes. Of course if you need to port C++ code across platforms, which can easily happen if code is to survive a decade, then even if the built-in type sizes don't change, you'll have to deal with things like there being no standard build system for C++, no standard interfaces for most of the functionality found in an OS, etc.

Overall, while C++ indeed is fairly stable, I wouldn't bet on C++ code to be easier to drag into the future than code in those other languages (of course I wouldn't easily bet the other way, either; it's hard to know in advance with these things which will bite you the hardest.)

> code written 10 years ago will not compile as C++11 without changes

I have a lot of projects from 2002, 2003, 2004, 2005 and 2006 that compile and run just fine. All those use "make" as a build system.

I even have some stuff was developed using Borland's Free C++ compiler (5.5) and with a few minor fixes to #pragmas and #includes it compiles using clang and GCC.

Source? I've never had an issue compiling legacy code.

C++14 deprecates a couple of things in the library, and trigraphs are going away "soon".

Then don't set the C++14 flags.

Personally I never seen a C++03 program that doesn't compile in C++11/14.

Obviously, if you are talking about C++ code written before C++ was standardized, like in the 90's, you are probably right.

I've seen and ported such programs. I no longer remember what the problems were, but I think some of them had to do with array initializers - C++11 seems to have become stricter wrt implicit casts of values used to initialize arrays (meaning that more casts need to become implicit.)

Perhaps it's a compiler issue, not a language issue; my only point is that the issue exists (and I'm not saying it was that terrible - I recommend everyone to upgrade to C++11 - just that code will not compile unchanged.)

Sister comments say that they have old C++ code that compiles just fine. Of course such code exists, I'm just saying that not all code is like that; I bet you can get there with Rust or some other reasonably stable new language if you program conservatively enough. Also a big question is what platform your code runs on; if you've targeted gcc since forever and you don't use -Werror, then your code and your Makefiles will be very stable relatively to having to port to VS - even if you're not really targeting standard C++ but the dialect GNU C++. Different C++ compilers, build environments and platform libraries are very different, and it seems a safe bet that newer languages will do a better job of minimizing differences between implementations (or keeping their number small.)

Porting C++ code compiling fine under g++ to clang, for instance, is a metric ton of work (and this one I gladly wasn't involved in but I've seen others do it; again, if your C++ code ports just fine, more power to you.) And g++ and clang are much closer to each other than the average pair of C++ compilers.

I've "ported" ~200k lines of C++03 to C++11 and so far I've had to make exactly one change due to language changes (C++11 forbids narrowing conversions in braced inits, while C++03 just did nonsensical things). That's not to say that no other changes were required, but the rest were things like fixing code that had both C++03 and C++11 versions and the C++11 version was broken, and fixing compatibility issues with libc++.

Ok except for language stability which is by the way one of the reasons C++ is lagging behind. For anything other than that I would not recommend C++. The day C++ offers modules, a package manager like Python pip or rust cargo and a multiplatform build system (there is cmake but still) I would reconsider. I am not saying C++ is no more viable, far from that actually, take the swift compiler for example is written is C++ and for that kind of software C++ is excellent (fast, stable etc.) but down the road I am sure it's going to be less popular for the kind of applications for which it's/was considered the only viable option.

Of course, because you can be 100% sure that your C++ program does not contain any subtle undefined behavior that was already disallowed in the C++98 standard and which next decade's more advanced optimizing compilers would turn into hilarious machine code.