7 ms·

This is totally true. The downside, of course, is just how much code exists that is written in pre-C++11 dialects, and how many programmers are trained to writ

• dfan 12y ago
  Also, how many companies are afraid of the new features and deprecate them internally (fearing compiler bugs, lack of portability, and/or unmaintainability). I still haven't had a chance to use full C++11 in a professional context.
  • tdees40 12y ago
    Oh my goodness, yes. The HN crowd probably doesn't appreciate the extent to which people who sling C++ at BigCorp are limited by the rules the company sets.
    • jsmeaton 12y ago
      It's not just C++ either. "What do you mean you want to use LINQ (in C#)? No one understands that rubbish".
      • voltagex_ 12y ago
        * Don't use LINQ * Don't use var * Don't use dynamic or even better, "You've only got .NET 2/3 installed"
        • guiomie 12y ago
          I can't look at code without var's anymore.
      • mhd 12y ago
        "We haven't vetted anything other than Java 1.4 on our BigAutoCorp PCs, so if you want to write a desktop app..."
      • jahnu 12y ago
        And should Go or Rust achieve widespread adoption the same thing will happen to them. So the point is moot.
  • kyllo 12y ago
    Like Google for example? Their C++ style guide is pretty restrictive, here's an expert C++ programmer's takedown of it: https://www.linkedin.com/today/post/article/20140503193653-3046051-why-google-style-guide-for-c-is-a-deal-breaker https://www.linkedin.com/today/post/article/20140503193653-3...
    • yongjik 12y ago
      FWIW, things like range-based for loops, "auto", and unique_ptr are pretty standard in Google these days. Still no exceptions, though. The thing is, when you have a single codebase that is maintained by thousands of engineers, you have to make concessions. There is no place for "rockstar programming": everything must be, in a sense, bland, so that it blends seamlessly into the work of thousands of others.
      • Silhouette 12y ago
        Not that I disagree with your real point about writing maintainable code rather than "clever" code, but if you have a single codebase that is maintained by thousands of engineers then I would argue that you're probably doing something horribly wrong already, and using exceptions is hardly exclusive to so-called rockstars. I don't really understand organisations that still use C++ in 2014 but then knock out such fundamental parts of its functionality, but then looking at the design priorities for Go, clearly at least some people at Google have very different preferences to my own, so YMMV etc.
        • yongjik 12y ago
          I agree that using exception is hardly noteworthy these days, but consider that in the context of a codebase that has evolved for more than a decade. I guess, ten years ago, "let's not use exceptions; they aren't worth it" was more justifiable. In any case, the decision was made, and we have millions of LOC where every single API is built with the assumption "No exceptions here." In that context, introducing exceptions seems suddenly a lot more trouble than its worth. Well, YMMV, and in any case I'm not a decision maker so what do I know. * BTW, I think "a single codebase maintained by thousands of engineers" is the single best thing I found in Google, as it opens up infinite possibility of learning new tricks, new APIs, and sometimes new projects. (Of course, everybody complains that every API is implemented at least three times, but imagine how worse it would have been if every project had its own codebase.)
• wfunction 12y ago
  > The downside, of course, is just how much code exists that is written in pre-C++11 dialects, and how many programmers are trained to write that sort of code. I do the same thing. Not because I can't write C++11, but because I still encounter systems with older compilers that I want to run programs on. What, is this surprising? Let's face reality: it's a little unreasonable to expect every system you work on to have a compiler less than 3 years old. Especially true on older Linux systems, it's sometimes a massive pain or even pretty much impossible to upgrade the existing compiler in a package-manager-friendly way (try upgrading Ubuntu 12.04's compiler to GCC 4.9, for example), so you'd have to compiler the compiler from scratch. Which is a pretty massive PITA and more or less requires a PhD of its own for GCC (Clang is a little better). And on Windows VC++ isn't always exactly following the correct standard. It's not necessarily outright impossible, but it's pretty impractical.
  • jevinskie 12y ago
    When LLVM started to require C++11 (which we use as a library), my team decided to statically link libstdc++ into our product on Linux. Now we just depend on glibc (and we use symbol versioning to keep the required version to a minimum). It sounds like you ship source though, so it may not be an option for you.
  • Guvante 12y ago
    > Let's face reality: it's a little unreasonable to expect every system you work on to have a compiler less than 3 years old. If you are running Linux, this is one thing that Windows gets right. (Although as you say VC++ has some catching up to do still).
    • adrusi 12y ago
      Linux is on all parts of the spectrum here. Ubuntu LTS and Slackware are going to remain outdated by design. Arch Linux almost always have the most recent stable releases of GCC and clang, and you can even build development snapshots from AUR
      • 12y ago
• sdegutis 12y ago
  Meh, breaking backwards compatibility isn't all that bad. It will be a bit rough for a few years, but it's worth it to clean things up for a brighter future.
  • untog 12y ago
    The example of Python 3 is a good one. "A bit rough for a few years" might be an underestimation.
    • sdegutis 12y ago
      I don't think Python 3 is a good example. Unlike other cases where languages broke backwards compatibility, the Python community actively discouraged upgrading for years, constantly saying "don't use Python 3" for years, and Python 2 was actively maintained in parallel to Python 3, with features constantly being back-ported. It would have been much smoother overall if they'd just dropped Python 2 altogether, even if a little more painful up-front.
      • pmelendez 12y ago
        I believe he was being sarcastic. And breaking backwards compatibility can be really bad. Imagine if the next version of C would break the previous one. How many operating systems and critical software would have to be rewritten in order to be maintained.
        • cwyers 12y ago
          Python is in a different boat than C++. If the Python language leaders decides to make a version that breaks backwards compatibility... well, they also make the most popular Python interpreter. The group responsible for the C++ standard isn't in the same position at all, they have to convince the different compiler groups (GCC,LLVM,Intel,Microsoft,etc.) to implement it for them.
          • pmelendez 12y ago
• bluetech 12y ago
  Maybe they can use something like javascript's and perl's "strict" annotations.
• Nursie 12y ago
  The main downside I can see with it is how much implicit behaviour there is. Sometimes it's very hard to figure out what's actually going to happen with a line of code. That said it's quite expressive now, you can do a lot with a little code, which is always nice.
  • blt 12y ago
    Yes. As much as I love C++, I sometimes get very scared by the implicit behavior. This is why I don't understand the hate on exception-free, more C-like C++. You can still reap huge benefits from std::algorithm, iterators, classes, templates, while stepping back to a more manual approach for allocation and lifetime management.
    • JoeAltmaier 12y ago
      You definitely have to pick and choose from C++ based on environment, your staff's experience, what kind of problem you're solving. Allocation in particular is problematic in every language (even GC languages) especially when latency is an issue, so that's probably what I manage 'manually' most often.