- C style error codes
- minimal use of STL
- use of templates is frowned upon
- C style enums
This just of the top of my head, I would need to read it again to see if they changed anything.
- C style error codes
- minimal use of STL
- use of templates is frowned upon
- C style enums
This just of the top of my head, I would need to read it again to see if they changed anything.
I was recently reading the docs for a physics engine in c++ and they said that its initial implementation used std::vector in many places, but they instead implemented their own in later versions to accommodate maximum "portability and compatibility." I wonder what that means? Since the STL is included in C++ compilers and vector is always going to be there, why would they need to roll their own to make the engine either more portable or more compatible?
>use of templates is frowned upon
I wonder if this means the writing of templates, or using existing templates. If the latter, maybe like the STL their primary concern is compile times?
Basically, Google has an enormous code base. Stylistic decisions should have semantic weight, but since everybody has their own style, it becomes challenging to understand the reasoning behind certain choices. When you have a standard, it means that you can read into some of the stylistic decisions sprinkled throughout the code.
Take for example, the use of pointer arguments for passing the addresses of results. The justification is that using a pointer is explicit and unambiguous. Non-const references have value syntax but pointer semantics, which can be confusing. Yes, this is contrary to some of the core values behind C++ but Google felt that the improved readability was worth that dissonance.
Do Google enforce const pointers for arguments that define where to store results? If not, you could delete the pointer they pass you. A pointer does not always indicate who owns the data clearly.
Far better would be to return the values from the function (or std::move them out if you must) instead of using a parameter as a "dump your results here" flag.
Stroustrup encourages this (see 5.3.3 of C++ 4th edition where he says "I don’t consider returning results through arguments particularly elegant"). IMHO, it would be better to return a std::pair<bool, std::vector<myWonderfulType>> where bool indicates the success/failure of the function, with pair.second item being the results.
You cannot ever known what a pointer is used for.
If the prototype has const, maybe just maybe, assuming the function doesn't cast it away, it is a read only.
So I never bought into this argument.
I imagine templates are frowned upon for the same reason -- too many moving parts. Otherwise they're perfectly fine to use in projects that have goals other than portably predictable performance.
Google around for Visual Studio 6 STL, and take into account the fact that most organizations don't upgrade right away, and you're looking at at least 2005 before you could rely on the STL cross-platform. Maybe much later.