Hacker News new | ask | show | jobs
by angersock 5382 days ago
Some entertaining bits from the article:

"How many Mac applications still support OS X 10.2? 10.3? 10.4?"

"Then why should we be so conservative when it comes to C++, the very core of what we work with?"

"C++11 is a much more productive language than C++98. We as an industry can, however, only reap that productivity gain if we stop throwing C++ productivity out of the window by the bucket-load in the hopeless pursuit of compatibility with non-standard implementations."

I'm as much for iconoclasm as the next person, but this whole C++ madness is starting to make me worry. While the rest of us have been off in the trenches of maintenance and production, some cabal of academics and chuckleheads has been cooking up this monstrosity of a language, and now it is finally coming to a head.

Folks, conservatism in software design is appreciated--in language design, essential. Python 3 is still not support by many useful libraries. Perl 5, over ten years later, is still in production and use. ECMA/Javascript is only now really taking off, after 15 years.

And on the darker, even more depressing side of things, you've still F77 codes in "production" and active maintenance--a friend of mine who is a graduate student is dealing with this right now. These are souls being fed to the gaping maw of legacy code.

I'm sure C++ has some interesting features. I understand, for example, why the "auto" keyword is being given new meaning (because the syntax of the STL, classes, and templates is so mindnumbingly awful!). I understand why explicit defaulting and deleting of function might lead to cleaner code (regardless of, say, an explicit that already exists). I understand why I might want 3 different declensions of 'u' in front of a string to support various forms of Unicode (where is your liberalism about forcing everyone to using UTF-8 and being done with it?).

I also understand that D probably has a better execution on these ideas than C++.

And that Javascript and C# have a better implementation of lambdas and closures.

And that for raw power and readability, C with embedded assembly (still!) can probably eat the lunch of any C++. (for an example of rational language evolution, see C1X: http://www.open-std.org/jtc1/sc22/wg14/ )

And that C++ still doesn't have anything other than a crackheaded set of half-idioms for exporting classes for dynamic linking in a crossplatform way, or even for binding to another language! Go ask the poor bastard who wrote SWIG's comments on the same--he quit programming for several years to stop dealing with C++'s increasing garbage.

I feel reasonable in saying this: C++ is not going away soon. One day (even sooner if you are in academic circles and dealing with libraries) we maintenance programmers are going to have to start dealing with code written to take advantage of the new features in C++11.

And on that day, all of us will be wondering why the hell we are still using that katamari of language features, instead of something less baroque--perhaps Perl.

1 comments

I think your missing a key point: C++11 is a better, cleaner language. It's not C++98 with a bunch more not-fully-baked and overly complex stuff thrown in. Much of the new stuff that's added is there to make the old complexity go away.

Most of the old mile-long redundant type definitions can go away now, being replaced with just the 'auto' keyword.

The old std:: argument binders were like poor man's lambdas. Now we have real lambdas and don't need them.

The old practice of defining tons of template overloads is no longer required because we have proper variadic templates now. To unfairly pick one example at random of what should no longer be necessary: http://svn.boost.org/svn/boost/trunk/boost/type_traits/detai... Of course this is special purpose-library code that isn't the kind of things most applications would need to write, but it could easily end up in a compiler warning or error message.

Sure, of the people who really didn't like C++ before then C++11 might not change all their minds. But for those of us who used and liked C++ already, these new features represent great simplifying improvements that are only going to help with ongoing maintenance.

The issue is that there are already many better, cleaner languages than C++98/03.

C++ is a good language, with some clunk to it. The best parts of it are arguably the bits inherited from C (which C++11 looks like it might break with). The OOPy parts (classes, polymorphism, etc.) have been done better by languages like Java, Javascript, and Smalltalk. Templates exist to get around grossness of the rest of the language, and were done better by Java's generics anyways. Multiple inheritance was done better by Java in the form of interfaces.

The rhetoric is that these changes somehow simplify the language--that's cool and all, and may even be true for the most trivial of examples or the most basic of beginners. The problem is that these new features are going to be released in the wild alongside many libraries who don't use them, being old, and who won't be updated, being cumbersome or trusted. And so, the burden of making the ends meet is going to fall on the rest of us who now have to support, in effect, two languages.

If the improvements are incremental, then this wasn't worth doing, If the improvements are such a new, cleaner, simpler language, why the hell call it C++? Again, see D.

Lastly, most of the fixes are syntactic sugar which do nothing to help fix some very real issues with the deployment of the language.

How do I bind these things to other languages cleanly? In C this is trivial--why isn't this fixed in C++11?

How do I load libraries of classes dynamically at runtime? From C wrappers?

When interfacing with old libraries (which actually do exist), how often am I going to have to write some kind of NULL-nullptr glue code?

Why do we not have variable length arrays (they're in C99)?

I'm nothing like an official C++ spokesperson, but I'll take a shot at these questions.

If the improvements are incremental, then this wasn't worth doing

Well maybe C++ is not your cup of tea, but I find the improvements worthwhile.

If the improvements are such a new, cleaner, simpler language, why the hell call it C++? Again, see D.

Yeah, I think it's a better C++ not an entirely new language.

Lastly, most of the fixes are syntactic sugar which do nothing to help fix some very real issues with the deployment of the language.

Systems languages are syntactic sugar for the underlying runtime model. I consider C++ to be a systems language (the ISO spec explicitly defines a minimal profile suitable for embedded systems for example). But C is probably a slightly more "systems" of a language (in no small part because it's the language which defines most system's APIs).

How do I bind these things to other languages cleanly? In C this is trivial--why isn't this fixed in C++11?

If you think this is trivial in C I suspect it's because you have so much familiarity with it and/or these other languages are implemented in C and define their external APIs directly in C. C has an unfair advantage in this regard, but it's just not that hard to integrate C++ and C.

Sometimes C++ has advantages too, some people swear by Boost.Python for example. Looks much simpler than C to me.

How do I load libraries of classes dynamically at runtime? From C wrappers?

That's one way. The main reason dynamic loading works in C is because the types are all so primitive (and it doesn't have "classes"). You can use those primitive types for your APIs and in C too.

Another way is to define the classes interfaces in terms of something binary stable over the scope you wish to separately compile these libraries. This requires some understanding of the guarantees of the platform and complier/linker. MS-COM for example gets a lot of mileage out of some relatively minimal abstract class layout conventions.

When interfacing with old libraries (which actually do exist), how often am I going to have to write some kind of NULL-nullptr glue code?

I've been writing some C++11 with C++4.6.0 and a bunch of old libraries and haven't run into that. I don't use pointers in my code very much, so I don't think I've even had to use nullptr yet.

So I would think "not very often", at least if your coding style is similar to mine.

Why do we not have variable length arrays (they're in C99)?

I don't know why the decision was made in the language committee, but std::vector with the new initializer syntax works well for me for that purpose. Perhaps the C99 construct could be a little more efficient, but I don't see a reason that an alert compiler couldn't also allocate the storage on the stack.

About variable length arrays: Scott Meyers pointed out that this code std::vector<int[n]> a; // n is a runtime argument has no real meaning in C++. Also std::vector and std::array already cover the use case.
Thank you for your helpful response!

C has an unfair advantage in this regard, but it's just not that hard to integrate C++ and C.

This is very true... as you pointed out C is very primitive in a lot of respects, and this doubtless simplifies working with it from other languages. The question is, how do I easily call the new C++11 code from something like Lua, Java, Python, Ruby, etc.? How weird will my wrapping code end up looking?

I'm sorry to harp on this, but I'm in the middle of a medium-size engine codebase written in C++, and even with our restraint so far on the use of some of the more advanced language features, things like smart pointers and whatnot are so useful that they become a concern (multithreaded code without smart pointers is a recipe for madness).

I've been writing some C++11 with C++4.6.0 and a bunch of old libraries and haven't run into that. I don't use pointers in my code very much, so I don't think I've even had to use nullptr yet.

Out of curiosity, how much have you done with OpenGL/OpenAL/OpenCL, etc.? Have you had any issues there yet? I'd like to know if that stuff fits okay with C++11.

The question is, how do I easily call the new C++11 code from something like Lua, Java, Python, Ruby, etc.? How weird will my wrapping code end up looking?

Well, no weirder at least than the older C++. Which is certainly a matter of perspective! :-)

In the ideal case, someone will write a C++ binding to your language that's even easier than C. Like I said, some people love Boost.Python but I haven't tried it.

I did play with Lua and C++ recently. The Lua interpreter itself can be compiled as C++! It will then throw C++ exceptions instead of using setjmp/longjmp, which is much saner IMHO. (I am really impressed with Lua.)

Just a feeling, but I bet that sooner or later somebody is going to come along and do something really cool with C++11 lambdas and that multi-language bindings problem.

I'm sorry to harp on this, but I'm in the middle of a medium-size engine codebase written in C++, and even with our restraint so far on the use of some of the more advanced language features, things like smart pointers and whatnot are so useful that they become a concern (multithreaded code without smart pointers is a recipe for madness).

Yeah. How does one code without smart pointers in their toolkit? I couldn't go back..(except when I have to thunk back to C for something).

Also, for multithreaded stuff, I'm getting addicted to the new std::atomics in C++11!

Not new with C++11, but have you tried Boost.ASIO for multithreaded IO? It is awesome.

Out of curiosity, how much have you done with OpenGL/OpenAL/OpenCL, etc.? Have you had any issues there yet? I'd like to know if that stuff fits okay with C++11.

I have, in fact, been doing some experiments with C++ and OpenGL in my spare time. Made some wrapper classes for compiled shaders and buffer objects and the like.

I had much of that code running before I switched to G++4.6.0 and starting allowing myself to depend on C++11 features, but I know I've extended it some since. I really don't recall noticing any difference in the switch.

One of the biggest advantages of C++ is something that many people miss. Much of that "ugly" complexity is in support of some design principles that are critical for large-scale software development: backwards compatibility (often back to C), and you don't pay for new features you don't use.