4 ms·

>Why not use boost intrusive lists? Yeah, why not? "The implementation is complex" is not a sensible reason not to use them; it's the complexity of the API one

by sjolsen 12y ago

>Why not use boost intrusive lists? Yeah, why not? "The implementation is complex" is not a sensible reason not to use them; it's the complexity of the API one should worry about, and it seems as simple as adding a link subobject. I wonder if the author of this article actually bothered to test the Boost implementation and its performance.

AlexeyBrin 12y ago
Most C++ hard core game developers don't even use the STL that comes with the language ... Why do you think they will even consider linking the huge Boost library with their game ? Also, the use of templates is usually a big no - no for most game dev studios.
- sjolsen 12y ago
  >Most C++ hard core game developers don't even use the STL that comes with the language ... Why do you think they will even consider linking the huge Boost library with their game ? Boost has libraries that address specific efficiency concerns like the one the article discusses; the standard library containers don't. You also don't link with the entire Boost library. You link with the components you use, which in the case of a library like intrusive/list is whichever member functions you use from each container instantiation you use. That's a static link, too. But no, I don't really expect anyone who considers themselves a "hard core" programmer to consider using a library like Boost. >Also, the use of templates is usually a big no - no for most game dev studios. Do you have a specific example?
  - grandmaster789 12y ago
    Well, I know for a fact that the Unreal Engine doesn't use STL. There used to be quite a large variance in the quality of any STL implementation and when you care about each single instruction that gets passed to the CPU, you turn a bit into a control-freak. Some gamedev's also dislike interacting with STL code because of the metaprogramming in there and the associated error messages produced. Heavy template use makes compilation terribly slow, which is undesirable when you're trying to do a couple of quick iterations of code. These are issues that can be avoided simply by just not using STL and templates in general, or very sparingly. The downside is that you need to roll your own of everything, with all of the bugs and devtime implied...

by sjolsen 12y ago

AlexeyBrin 12y ago

Most C++ hard core game developers don't even use the STL that comes with the language ... Why do you think they will even consider linking the huge Boost library with their game ? Also, the use of templates is usually a big no - no for most game dev studios.

sjolsen 12y ago
>Most C++ hard core game developers don't even use the STL that comes with the language ... Why do you think they will even consider linking the huge Boost library with their game ? Boost has libraries that address specific efficiency concerns like the one the article discusses; the standard library containers don't. You also don't link with the entire Boost library. You link with the components you use, which in the case of a library like intrusive/list is whichever member functions you use from each container instantiation you use. That's a static link, too. But no, I don't really expect anyone who considers themselves a "hard core" programmer to consider using a library like Boost. >Also, the use of templates is usually a big no - no for most game dev studios. Do you have a specific example?
- grandmaster789 12y ago
  Well, I know for a fact that the Unreal Engine doesn't use STL. There used to be quite a large variance in the quality of any STL implementation and when you care about each single instruction that gets passed to the CPU, you turn a bit into a control-freak. Some gamedev's also dislike interacting with STL code because of the metaprogramming in there and the associated error messages produced. Heavy template use makes compilation terribly slow, which is undesirable when you're trying to do a couple of quick iterations of code. These are issues that can be avoided simply by just not using STL and templates in general, or very sparingly. The downside is that you need to roll your own of everything, with all of the bugs and devtime implied...