Which is kind of true if you can stick with the standard library and control which compiler gets used.
Back in those days, we were deploying code across heterogeneous OSes (not all POSIX), using the OS vendor provided compilers, which were still catching up with C++98, let alone C++03.
So this really restricts how much you can make use of the standard library and which third party libraries to use in a portable way.
I covered exactly this. I write code for windows/Linux/Mac OS X. Write a class to contain those ifdef. I did this before C++11 as well.
This isn't a new technique, but for some reason people adopting C++11 and C++14 seem more willing to do it than people who wish C++ was really just C with classes.
Also, write unit tests to test the class. Run the Tests in CI on every platform and a variety of configs. It is not hard and there great free or cheap tools Like Jenkins, TravisCI and Appveyor.
> This isn't a new technique, but for some reason people adopting C++11 and C++14 seem more willing to do it than people who wish C++ was really just C with classes.
This was exactly part of the problem.
Most of the enterprise code I used to deal with was not even that, rather compiling C with C++ compiler.
However my point with rich runtimes was that you shouldn't bother to even do that, the runtime is the OS, kind of.
You can treat your minimum version of C++ as its own language if you want. Then a platform not supporting it is the same thing as a platform that doesn't support your chosen rich runtime.
Nothing forces you to start using non-portable code to reach more devices. It's strictly an option, and you can emulate a rich runtime by always answering "no".
Back in those days, we were deploying code across heterogeneous OSes (not all POSIX), using the OS vendor provided compilers, which were still catching up with C++98, let alone C++03.
So this really restricts how much you can make use of the standard library and which third party libraries to use in a portable way.
Then is time for #ifdef party.