|
|
|
|
|
|
by helmut_hed
4044 days ago
|
|
|
The Google guidelines are... somewhat out of sync... with the intended use of language features as described in the Standard and the recommendations of people associated with it. They seem to take as a starting assumption that the language is misdesigned and major parts of it should simply be avoided or used in unintended ways. If you agree, it's a perfectly fine guide. Otherwise, I'd recommend reading any of Scott Meyers' or Herb Sutter's books and following their advice. |
|
|
But Exceptional C++ made me not want to deal with C++ exceptions, ever. If getting C++ code correct in the face of exceptions is that bloody hard, then the language is broken. I'm convinced that cobbling up an "int" equivalent type that is exception safe is a pyrrhic endeavor that will be a continual source of fragility in production code.
Alexandrescu's Modern C++ Design made me want to forget that templates ever existed. The entire second half of that book I kept saying to myself, "If I'm on a project with someone actually checking stuff like that in, one of us is going to have to leave." Fortunately I've yet to run into those kinds of template metaprogramming games in the wild. Good programmers seem to abhor them.
[Edit: Actually, I remember a bunch of stuff in Modern COM that used templates very heavily. Essentially impervious to debugging; that stuff sucked hard]
More recent C++ design decisions are better than the ones the committees made in the 90s and early 2000s. But the successful teams I've seen all practice restraint and keep things debuggable by limiting the amount of magic going on under the hood, regardless of what the committees have been pushing.
The Google C++ standards (and others that were independently created and haven't been seen much outside their own development cultures) may be "dated", but they remain an indictment of the design of C++.