Hacker News Reader

Comment by hellofunk | Hacker News Reader

>minimal use of STL

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?

View on HN

Use of templates isn't frowned upon. TMP is frowned upon because usually the performance gains don't justify the loss of readability. It has been said many times in many ways: don't write code for yourself, write it for others.

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.

I would have thought that non-const references was better? It is clear that a non-const reference can be modified. If I just wanted to let them read a value, a const reference would be clear.

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.

Pointers have the advantage of signaling a return value at the call site without having to look up the function prototype.

Which I don't agree with, given the amount of pointers that fly around in C codebases.

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.

std::vector spec leaves quite a bit of performance-critical details unspecified. I imagine the allocator behaviour differs enough between implementations that they implemented their own to keep performance in different platforms more predictable. The performance requirements for a physics engine can be quite different from the general case that the std::vector spec is aiming for.

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.

Good points, I hadn't considered that the implementation of a vector could widely vary. That makes sense.

Yup, the spec is also really vague on if clear() actually releases memory. AFAIK the only "correct" way to actually clear a vector is "vec = std::vector<T>()" with the STL.

That is rather interesting!

Actually you'd have to try harder: even this might leave the current capacity unchanged. The blessed idiom is vec.swap(std::vector<T>()); c++11 added shrink_to_fit which is a non binding request to reduce capacity.

It probably means that it was written before we had a complete and correct implementation of the STL on all major compilers.

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.

Reply on news.ycombinator.com