The Sorry State of C++ Portability
jeffwofford.com
jeffwofford.com
As usual with native code, portability is actually quite easy to achieve - except to Windows using MS's native tools.
You can't just sort of tack portability on at the end, by targeting one system and then trying to build on the other one(s) right at the end. That's just going to involve a pile of work, that you could avoid. If you build on all of the systems you target, all the time, and fix problems as they arise, it's much easier.
There was (and maybe still is) this notion that portability for Windows programmers consisted of "Windows '95 AND Windows NT". There might be a newer version of the saying these days, probably "Windows 7 32-bit AND 64-bit". But anyway, it was rightly used as a stick to beat Windows programmers with. But the competing approach, of sticking to gcc, maybe using POSIX and pthreads, perhaps relying on fork a lot, etc., etc., and then crying foul when it won't work on Windows... well, that's always seemed to be perfectly acceptable for some reason ;)
The problem with POSIX, like any other standard, is that not all systems implement the same POSIX.
Additionally there are APIs which have undefined edge cases or different limits (e.g. amount of open file handles).
So even if you only target POSIX systems, you have to pollute the code with #ifdef to handle such differences.
It is similar to do web development. There are standards, but each browser version is a different world.
But it's certainly possible that Windows is even more bizarre than I suppose, in ways that I have yet to encounter.
It was interesting watching node/libuv face all the same problems I did when originally trying to abstract over this.
http://web.archive.org/web/20110719052845/http://developers....
Besides, the issue explicitly brought up was the fact the Microsoft C++ compiler does not fully support C-11.
As for your other point, it's indeed true that some systems are more like some other systems, and not like others. But so what? If you want your code to be portable, it needs to build on all the targets you support. So you need to do that. Perhaps people assume there's some magic bullet, or secret special thing that you can do? Sadly not, just the usual - work and some forward planning.
I always hear statements like this from people that never did real cross platform development.
There are more operating systems in the world than just plain POSIX and Windows.
Even POSIX if one constrains to POSIX compliant systems, is a bag full of surprises due to undefined behaviours in the standard.
This is cross-platform coding 101...
There's your first problem.
I love C++11 to pieces.
... and your second.
Yes, I know that sounds language-war-flamey, but has anyone seen a more complex language with weird context-dependent behavior and strange side effects? The STL is a mess of weird APIs and often hard-to-understand behavior (and let's not forgot the utterly obtuse warning and error messages).
Every new revision of the language comes with a slew of new features bolted onto the language or standard library. All of them are arguably useful, but the standards process is driven too much by permissive committee, setting the bar very low (with regard to use-cases, not quality) for new features to be included.
I just feel like in this day and age, with such focus on code reuse, readability, and security over performance, C++ is a very dangerous language to work with.
(Having said this, a month or two ago I wrote a VoIP SDK in C++, mainly as an experiment. It was certainly easier to write in some ways than if I'd used straight C, but it was such a pain in so many other ways that I hesitate to consider my experiment a success.)
Also, it’s my understanding that new additions to C++ are very carefully considered. Far more proposals are made than make it into the standard. And just because you don’t see the use doesn’t mean that no one else does: the language is applied to a remarkably wide variety of problems.
Anyway, it is possible to write reusable, readable, secure, performant code in C++. Whether it’s worth it to try is another question entirely.
I write C++ code for a living, I also write in Python for that same living, and I have to say that C++ allows me to write safe reliable code just as well as Python. There is definite code-reuse, readability and security.
As for a complex language ... what programming language isn't complex, while still having full power?
As for the "obtuse warning and error messages", those are being worked on. Those didn't get solved simply by switching to a different language, that is something every single programming language is still working on... I still get errors in Python every so often with a huge stack trace and still have issues trying to figure out why it failed! Using clang and newer versions of gcc you now get error messages that are easy to read, easy to understand and in most cases the compiler will even tell you what you got wrong and suggests possible fixes.
I too love C++, I love C++11 and what it brings to the table. I am currently still targeting an older versions of the STL, mainly due to the fact that on OS X most C++ code is compiled against libstdc++, especially third party code, which is incompatible with libc++ when it comes to string handling. BUT I do get to take advantage of the language features, auto, variadic templates, iterator based for loops that are created for me, and lambda's.
The other thing with the new STL is that it allows the developer to write less code, and let the STL take care of cleaning up after itself. It is more exception safe, with shared_ptr<> and friends, and provides a native way to do threading without requiring calls into platform dependant code (it is abstracted away), atomicity and other tools that will help make C++ on multi-threaded/multi-core systems to do more work in parallel!
C++ has come a long way, C++11 is absolutely fantastic and has only made C++ even better than it has been before. It is a shame that valid C++ 11 code will not compile on VS2012 as it will mean we still have to do various hacks to get the same features on the Microsoft Windows platform.
Or their lack of C99 and C11 support for that matter.
Because GCC is easily available on those systems. Well and the fact that those systems are far from being mainstream and come with a bunch of their own issues.
There are even AS/400 and VMS systems to play with.
btw. the IBM XL C++'s support for C++11 seems to be as good as the one in VC++ 2012. They don't have lambdas but variadic templates instead.
No standards driven language gets fully support at the same time across all vendors.
Visual Studio is (sadly) the gold standard on Windows. It may not be free, but companies (including startups) will pay for it if they need it. GCC is of course free, as is clang. You'd be foolish to pay for a toolchain unless you have very specific needs. So what other compiler vendors that make money off their toolchains are actually relevant for all but niche uses? I'd guess that their aren't any, but I can't claim to have comprehensive knowledge of everyone's toolchain needs.
1. Windows
2. Mac OS X
3. Linux
4. Some form of BSD
5. Oracle Solaris/HP-UX/IBM AIX
Compiling for the top three platforms solves 99.999% of my problems, especially if my code is meant to be used on the desktop. For the windows platform's primary compiler to not have support for standard C++11 features is definitely a deficiency.Vote with your pocket.
This is a ridiculous statement. Microsoft wants to focus on C++ and will not put out a C99 compiler. Why is that bad? They obviously feel their efforts would be better spent elsewhere. If you take a look at Wikipedia's list of C99 implementations (http://en.wikipedia.org/wiki/C99#Implementations) you will see that many of the compilers there don't have full implementations, even though the standard was approved 13 years ago. Yet I don't see people chiming in on any of those compilers to complain of a lack of C99 support.
Unlike MSVC though, these compilers have included the extremely visible features -- things like inline variable declarations, designated initializers, and variable length arrays. I don't think Microsoft should implement C99 in full, but partial support would help students trying to learn C on Windows.
Microsoft is not forbidding anyone else to develop C compilers.
The important features are available http://gcc.gnu.org/c99status.html
For everything else related to native code there is C++.
The company's official statement is explained in Herb Sutter's blog:
http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and...
But there is a certain amount of schadenfreude from their refusal to implement even trivial C99 features for over a decade to "concentrate on C++0x", and yet have by far the most lagging C++11 implementation that likely won't implement many features for years to come.
Many in the open source community only know GCC and tend to think everyone supports everything.
Since the early K&R C days, each commercial compiler vendor implemented the parts it liked to implement, while leaving out parts they were not so keen to provide.
In the bad-old-days, of course, there was little choice but to use whatever (typically bad) commercial compiler one had available. So although these compilers generally sucked, that was just SNAFU.
But now things are different: GCC, and now Clang, provide high-quality and timely support for a wide variety of targets, and have set the bar much higher. The sucky commercial compilers of the past aren't really acceptable anymore.
http://software.intel.com/en-us/articles/c0x-features-suppor...
But in any case I find visual studio a horrendous piece of garbage.
was this really necessary? I'm quite sure that Microsoft is smart enough to implement the C++11 standard, so why it isn't implemented is actually more nuanced than "they're dumb lol". Could it be that you're one of a very small minority who would run into these problems?
Finally a OO language with proper use of Strings, exceptions, classes and available library, without having to litter your code with #ifdefs to manage portability across compiler vendors and operating systems.
Or reducing yourself to the common subset usually available, which has a bit hard to have across C and C++ compilers around 1996.
Nowadays we know better, but it was surely a reason among many others, for Java's success.
I state this, because I saw it happen live in the trenches back in the day.
Of course the people working on VC++ aren't dumb. But Microsoft is apparently not investing enough money. So it's absolutely necessary to call them out.
Popular vendors taking many years to implement new language standards is a huge problem. It means fragmentation and lack of progress for years to come.
Obviously Microsoft(or any other platform maker) does not want you to easily port your Application between platforms, but this does not mean the language is in bad shape.
Also, "The sorry state of WebGL" because Microsoft has decided not to support OpenGL.
You don't need to use Microsoft products. They are plenty of alternatives today.
Unless you want to sell native software to the ~400 million Windows users worldwide. Regardless of how you feel about the platform, it seems foolish to fault someone for trying to sell software on it.
$ cat test.cpp
int main() {
return ([]() { return 5; })();
}
$ clang++ -std=c++11 -o test test.cpp
$
Xcode 4.4.1.main.cpp:7:30: current parser token ')' main.cpp:5:1: parsing function body 'main' main.cpp:5:1: in compound statement ('{}') clang: error: unable to execute command: Segmentation fault: 11
Too bad we are now locked for next year or so. (and of course 4.4 doesn't support OSX 10.6, so no C++11 for us anyway...)
So it's not like the standard came out and everyone was like "whoa, new stuff we have to do". It came out piece by piece, and at some point was declared done. Like HTML5, only more organized and it got finished :)
This is why, for example, GCC and clang have had mature implementations in them for years.
In fact, GCC/Clang/et al having implementations was pretty much a pre-req to finishing the standard because they were used to discover bugs and issues in the proposed standard.
(edit: I'm simplifying a bit, since GCC, et al have had to make bug fixes for draft vs final incompatibilities and bugs that were discovered, but they are still relatively mature)
Ada, C, C++, Pascal, Algol, PL/I, Common Lisp, among many others, always have different levels of standards compliance level across compiler vendors.
This is the price to pay for ANSI/ISO standard compliant languages.
The other option is to have languages like e.g. Python with a single open source implementation across multiple operating systems. Or proprietary languages where the vendor decides to support multiple systems.
GCC and FreePascal are two compilers of ANSI/ISO languages for multiple OSes.
The problem is that they may not exist on the OS you care about.
> Windows command lines, and makefiles. CMake can help take the edge off managing a project’s build process, but this, too, is a new, non-trivial skill to learn.
And this makes me feel all the wierder, as someone who doesn't use Microsoft tools ever and is used to terminals, vim, and makefiles, but still can't comprehend some of the language features of C++11.
This pattern can be seen mirrored across many of Microsoft's products; Internet Explorer, Office, XBox etc.
> Perhaps by 2014 or so, Microsoft will have overcome their intellectual challenges.
Oh developing a game is different than implementing in a complicated feature in legacy code. Especially when that legacy code is relied upon by businesses all over the world including your own. I'm not feeling sorry for him anymore.
He didn't have to use a bleeding edge version of C++. The standard is less than a year old and it's a very well known fact that it's not fully supported by any compilers, and that all of the compilers have different levels of support.
If building with multiple compilers was important to him, then this is his own screw up, not Microsoft's.
It seems to me that your assertion is basically equivalent to, a few years ago, telling people to stop using newer HTML features that most browsers support because IE didn't support them. Sure, maybe stay away from bleeding edge features, but there comes a point in time where you have to stop blaming the user because Microsoft can't get their act together.
If anything, that makes me even more likely to blame the user. Microsoft always lags behind on stuff like this, why would anybody expect them to change now?
Now the shoe is on the other foot.
Microsoft's C++ compiler has always been wayyyyy behind in implementing C++11 features.
Back in the IE6/IE7 days, Microsoft wasn't beating the drum for developers to code to HTML5. But that's exactly what's happening now - Microsoft is evangalizing C++2011 but they can't get their crufty old compiler to build that code.
Combine that with all the really bad memories left over from older MSVC versions and the aggressive propaganda about modern and easy C++. MS simply needs to get its act together.
I don't really feel any sympathy here--for the C99 part, okay, but otherwise, none whatsoever.
Look at the http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... . It has been in decline since 2005!