Hacker News Reader

Comment by dfan | Hacker News Reader

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.

View on HN

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

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.

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.

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

This is of course a valid reasoning to forbid the use of some features at this particular company. However, it renders advocating the Google C++ style guide as an ubiquitous style guide for all C++ programming rather moot.

Completely agree. I hope nobody's naive enough to say "Well, if this style guide works for Google, it sure should work for our company...!"

Not adding much value here, but it is a lot worse. You get 5+ implementations everything, and every project is different just because.

Perhaps you would have less millions of LOC if you could reuse third-party libraries which happen to use exceptions?

Also no exceptions implies no failing constructors which is plain ugly as a constraint.

This article is a bit strange. Complex initialization in a constructor can make it more difficult to unit test a class. Copy constructors aren't prohibited, it's just recommended that you remove the implicit versions when your class shouldn't be copied. Some of the C++11 features were blacklisted because Google has had its own implementations. In some cases these C++11 features are now allowed and the previous implementations have been deprecated, it's just that the conversion process took time.

In general if you're going to work with other people I believe you need to be a bit flexible on coding with them rather than trying to be hard headed about your own style. It's important that people not be surprised when they work with your code.

The guide that's publicly available says "If your class needs to be copyable, prefer providing a copy method, such as CopyFrom() or Clone(), rather than a copy constructor" I think that's insane. Or, at the very least, surprising to encounter when working with someone else's code.

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.

It's not just C++ either. "What do you mean you want to use LINQ (in C#)? No one understands that rubbish".

* Don't use LINQ

* Don't use var

* Don't use dynamic

or even better,

"You've only got .NET 2/3 installed"

I can't look at code without var's anymore.

"We haven't vetted anything other than Java 1.4 on our BigAutoCorp PCs, so if you want to write a desktop app..."

And should Go or Rust achieve widespread adoption the same thing will happen to them. So the point is moot.

Reply on news.ycombinator.com