Across how many compilers and operating systems is your code portable without any problems?!

When written with discipline C++ is very portable. I've worked on codebases that spanned devices with ~8mb of memory to full-blown desktop PC and arches(x86/MIPS/ARM/PPC just to name a few).

Writing with discipline is a synonym for writing castrated C++, to avoid touching language features not yet implemented or with slight semantic differences across compilers.

One of the things that attracted me to Java was that I finally could write something where I could use 100% of language features and actually use it everywhere.

C++17 is around the corner, yet most embedded, mainframe and commercial UNIX vendors are between C++11 and C++14, in the few cases where they already support anything from C++14.

Then there are the UB and implementation defined differences across those compilers.

Across devices it seems it is very portable.

Now, across compiler vendors and versions it is hard

Generally speaking when you are targeting that wide of a range of devices you are targeting a wide range of compilers. It requires some discipline but it's far from the hardest thing in the world assuming you are regularly building and testing for all platforms. I'd say that most major C++ applications or libraries compile in Clang, GCC and MSVC without issue and often build for less common targets as well (icc, nvcc for cuda support, etc.) Things definitely get harder when you move to weirder embedded platforms.

Yup, we targeted GCC, MSVC, plus a few proprietary compilers. As long as you stick to a reasonable set of features(which you should anyway for sanity reasons) it works pretty well.

Having a good CI is a must though but it's not nearly as hard as porting an old codebase backwards.

It's just a configuration problem - at one job, we had a million line code base compiling with clang, gcc (2 versions, can't recall which), on 2 versions of solaris, 2 versions of linux, and linux 32bit and 64bit, plus windows on VS2010, and 2015, so that makes 18 *nix builds and 2 windows builds, so 20 different C++ builds of one code base. All unit tested, and regression tested. Get your CI system of choice working, e.g. TeamCity, fix your makefiles, and you're good to go.

Having done C and C++ across UNIX and Windows, during the late 90's throughout mid-2000's, using the OS vendor's compiler tooling, it was a bit more than just configuration.

For example, back then aCC wasn't even fully C89 compliant.

Of course when one uses the famous trio (gcc, clang, msvc) the world gets simplified a lot.

So when your cloudbleeding, your atleast doing it as fast as possible, right?? ;)

Sure if u write game engines, do it in C/C++. Embedded devices? Probably a good choice.

I work at a startup, and we only have a few devs. I share my C# code-base across the client/server/mobile platform and even cross-compile it to a few other lauinages in between. If i need speed, i just extern out to a C/C++ dll i need and get it (never need to). Or integrate a microservice in eralang.

C# is just like C++, to write fast code, u need to understand the hardware. Its just C#, the hardware includes the garbage collector.

>Sure if u write game engines, do it in C/C++. Embedded devices? Probably a good choice.

Bingo. Those two things are exactly what I do professionally and as a hobby.

There is Rust now. Why stay with C++?

Comments like this appear on HN with frequency, and they betray a complete detachment from reality. Like what an outsider would think looking at the industry.

A very mature language, rapidly evolving, with an enormous volume of well proven libraries and tools, or a cutting edge, barely production level (with a breaking changes language), tiny library new toolset. And you question why someone doesn't just transition? Is that serious?

> barely production level (with a breaking changes language)

Oh no you didn't.

There's an argument to be made in Rust vs C++ but to my knowledge there hasn't been a breaking change in Rust since 1.0 and there's been a ton of work to keep it that way.

There technically have been some small changes, just like in C++.

The key is, as you said, you aren't even sure there were ones. That's how we like to keep it, and that's part of where all that work goes. The rest goes into making sure nothing breaks accidentally :)

Trivial example: shortly after 1.15 was released, a new API was found to have a soundness hole, so a breaking change was made to fix it in 1.15.1.

Because you like the ability to dynamically link to your dependencies so the entire world doesn't need to be rebuilt just to upgrade libxyz.

I love Rust, and I've been trying to get a hobby project written in it - but it really stinks that I can't just rely on my distribution to keep dependencies up-to-date like I can something written in C or C++.