Re:New Features in C# 7.0
by pjmlp on Thursday March 09, 2017 @06:24PM
(#13834832)
Across how many compilers and operating systems is your code portable without any problems?!
[ Parent
| on HN ]
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.
Re:New Features in C# 7.0
by raverbashing on Thursday March 09, 2017 @06:55PM
(#13835031)
Across devices it seems it is very portable.
Now, across compiler vendors and versions it is hard
Re:New Features in C# 7.0
by Impossible on Thursday March 09, 2017 @08:40PM
(#13835624)
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.