3 ms·

> avoids STL containers I'm not sure I fully understand why some projects so proudly avoid using standard library features and e.g. favour a more manual approa

• deleted 3y ago
  [deleted]
• dundarious 3y ago
  Sprinkling small malloc and free-s everywhere, where every object has their own individual lifetime to be managed, is very often not the best approach. Using STL containers often means using that prolific allocation strategy -- it just makes the numerous small allocations implicit. A region based approach is often far simpler conceptually, and more performant. This is a decent article on the topic: https://www.rfleury.com/p/untangling-lifetimes-the-arena-allocator https://www.rfleury.com/p/untangling-lifetimes-the-arena-all... C++ is a big language and there is a lot of diversity of opinion in what a sensible subset of the language is, with numerous concerns influencing those decisions -- one common one is compile times. Using C only headers generally ensures a much lower ceiling for compile times compared to using typical C++ headers. And C++ headers are slightly more likely to use the prolific allocation strategy from above. As such, C++ headers require far more scrutiny before acceptance, in my view.
• _gabe_ 3y ago
  >> avoids ... C++ headers > Same question for this point - but is it the same reason as for avoiding STL containers or something else? ABI compatibility and the ability to easily create FFIs for other languages are the strongest appeals afaik.
• corysama 3y ago
  C++ compiler inlining capabilities have had to become magically powerful to keep up with the layers of small functions under every STL container method. Meanwhile, in some applications (games) high performance in debug builds is necessary. Same for headers, compile times matter. I'm very much looking forward to widespread, fully-modulized standard libraries.
• flohofwoe 3y ago
  One important reason is compile time. C++ stdlib headers are so entangled which each other that each one brings in tens of thousands of lines of complex template code, which may increase the compilation time for a single source file to seconds, and it's getting worse with each new C++ version. Also, it's not like writing your own growable array is rocket science, and a simple, specialized version can be done in a few dozen to a few hundred lines of code.
• turtledragonfly 3y ago
  Historically, in high-performance resource-constrained applications (eg: console video games), developers would use a "stripped down" version of C++ (eg: no RAII, no exceptions), which often included avoiding STL. It's less true these days, but still somewhat. In truth, STL will never be fully catering to these uses; that's not its goal. One reason STL was avoided is that control over memory allocation was quite poor. std::allocator was somewhat conceptually broken for a long time, only recently remedied in C++14 and 17. So, there's still about 20 years of code out there from the days of old bad C++ (: Another reason is that early STL implementations were poor, and not well-suited to high-performance use cases. Again, this has gotten better (some), but the legacy lives on. Here's a good one to read: https://github.com/electronicarts/EASTL/blob/master/doc/Design.md https://github.com/electronicarts/EASTL/blob/master/doc/Desi... So, if you are designing a library to be used in video games (such as in TFA), and want wide adoption, then avoiding STL, RAII, exceptions is still generally a good idea, IMO.
• dan-robertson 3y ago
  STL also has some kinda broken features, eg it’s hard to work with a std::vector<T> because everything is different when T=bool and then you get confusing errors if you happen to do that accidentally. std::vector<char> is also a bit broken though that’s the language’s fault rather than STL’s.
• johnnyanmac 3y ago
  When working in Unity, I was honestly shocked how much performance gain I got out of a small app by moving away from LINQ to using custom allocated containers. That convenience has a cost, and games can't afford such a cost.