6 ms·

Also, how many companies are afraid of the new features and deprecate them internally (fearing compiler bugs, lack of portability, and/or unmaintainability). I

by 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.)

by dfan 12y ago

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.)