Comments by "MrAbrazildo" (@MrAbrazildo) on "how Google writes gorgeous C++" video.

  1. 0:01, when I code, it's always gorgeous! :elbowcough: 0:08, I disagree. Modern C++ features are higher level ones, easier to use and less prone to errors. It's becoming harder to get things wrong with it! The price is raising chances to write slow-prone code. 0:55, TABs are better: uses 1 char and can be configured equally for all the team. I use TABs with size == 2. 1:05, neither draconian nor pedantic: the team must has the same rule about it, because it's an annoyance to see messed indentations. Once the team agrees about its size, use TABs. 1:20, are you saying that if TAB has the same size, it still may differ from 1 code editor to another?! 2:37, I can agree that, once the f() is done, a typedef is the better returning type. However, during its development, auto is much better: - More productive: it doesn't require to often change its type. - Defensive: if forget to return, it'll be deduced as a void value, raising compile warning if attributed to some variable later. 5:25, I don't use to have this "diamond problem". Mother and Father are not the same person, so each of them should inherit its own exclusive object of Person. Child is yet another person, not tied to parents. So it should inherit Person as well. I use to inherit classes when the derived 1 should has the power of change data of its bases. Except for Person, it's not the case. In real life, a child can change parents behavior by communication, not mental/physical interoperability. So Child should not inherit parents. Instead, its constructors should receive parents objects as 'const &', read-only stuff. Just as in real life: child receives a read-only genetic material from its parents, and is destined to be an independent person. 6:30, interface is too slow and just a bit higher level than a normal class. I don't use it, it's not worth. Plus, for those who use it, a better approach than an abstract class is to make a macro out of it. Then, by composition, call the macro inside the "derived" class, making it a normal class, 15-17x faster! 6:38, if a class has this limitation, I just make its constructors as protected, forcing inheritance.
    1
  2. I partially disagree. Auto can help performing automatic refactoring. Sometimes it's even defensive. But if you are not using an IDE, there are some tricks you can do. If you see: auto data = some_f (); //At DoComplexStuff file. You can force a compile error: class ForcedError { ForcedError (ForcedError &&) { printf ("ForcedError"); } }; //At some global space. ForcedError data = some_f (); //At DoComplexStuff file. Compiler will complain, indicating the type returned, maybe even opening/showing its source file, where it was declared. Then you create a typedef to replace that auto. Let's say it's ForeignType. On ForeignType decl file, you write: using foreign_type_t = ForeignType; //DoComplexStuff file needs this typedef. foreign_type_t data = some_f (); //At DoComplexStuff file. If they ever change ForeignType, you won't need to edit this line of code.
    1