[Debate]Using the STL in Games
Pages: 12
May I ask for exact STL containers/algorithms you have problem with?
My experience: array, const size vector (replaced with dynarray when it will be a part of standard) and unique_ptr have no overhead and can be used anywhere. List used with emplace, pool allocator and careful usage might be as good as homebrew intrusive list, but it depends. Ones which usefulness depends on implementation is associative containers so I would not depend on STL ones unless I take my implementation of STL with me. I would not use priority_queue even on PC and deque perfomance varies wildly depending on implementation (two stacks or independed blocks etc.).
One problem with STL is that you cannot be sure, unless you nkow your compiler and used implementation really good, if it would use most effective approach: will std::rotate or vector::insert use memcpy for POD types or will they use equivalent of for loop?
My experience: array, const size vector (replaced with dynarray when it will be a part of standard) and unique_ptr have no overhead and can be used anywhere. List used with emplace, pool allocator and careful usage might be as good as homebrew intrusive list, but it depends. Ones which usefulness depends on implementation is associative containers so I would not depend on STL ones unless I take my implementation of STL with me. I would not use priority_queue even on PC and deque perfomance varies wildly depending on implementation (two stacks or independed blocks etc.).
One problem with STL is that you cannot be sure, unless you nkow your compiler and used implementation really good, if it would use most effective approach: will std::rotate or vector::insert use memcpy for POD types or will they use equivalent of for loop?
You should never be concerned with efficiency when writing code, only when profiling code. I exclusively use the C++ standard library as much as I possibly can, and only adjust things that I find to be slow after the fact.
I'm a little disappointed that Cubbi and I weren't enough to point out that STL != C++ Standard Library.
http://stackoverflow.com/a/5205571/1959975
I'm a little disappointed that Cubbi and I weren't enough to point out that STL != C++ Standard Library.
http://stackoverflow.com/a/5205571/1959975
Last edited on
Even though I have already stated my opinion on it in the other thread, I'll just go ahead and reply here so everyone knows I've not changed my view.
@LB
I've said the same thing about efficiency in my old account and was chewed out by several members. I think it was in regards to arrays and 1d/2d/3d/nthd for efficiency. Think I even argued that the difference was so minute that it wasn't worth worrying over.
As for the link, I'm in the old school of thinking because I refer to the C++ Standard Library as STL (I know it is technically wrong, but old habits die hard).
Speaking of old habits, stating engines that don't use the standard library doesn't prove that it is evil. For all you know they are just using their implementations due to the old habit of using them in the first place. They more than likely just use what they are used to and know works rather than rewrite the whole engine just to see if the standard would work now.
Without seeing the full code, for all we know, they may not rewrite large chunks of the engine at all. They very well could have macros defined so they just change the platform flag during compilation to make builds for each platform.
@LB
I've said the same thing about efficiency in my old account and was chewed out by several members. I think it was in regards to arrays and 1d/2d/3d/nthd for efficiency. Think I even argued that the difference was so minute that it wasn't worth worrying over.
As for the link, I'm in the old school of thinking because I refer to the C++ Standard Library as STL (I know it is technically wrong, but old habits die hard).
Speaking of old habits, stating engines that don't use the standard library doesn't prove that it is evil. For all you know they are just using their implementations due to the old habit of using them in the first place. They more than likely just use what they are used to and know works rather than rewrite the whole engine just to see if the standard would work now.
Without seeing the full code, for all we know, they may not rewrite large chunks of the engine at all. They very well could have macros defined so they just change the platform flag during compilation to make builds for each platform.
Last edited on
| Speaking of old habits, stating engines that don't use the standard library doesn't prove that it is evil. For all you know they are just using their implementations due to the old habit of using them in the first place. They more than likely just use what they are used to and know works rather than rewrite the whole engine just to see if the standard would work now. |
First I would like to point out no one here ever said that using the STL was evil I don't believe. The debate was whether or not the STL should be/is used in games. We are not trying to say the STL is evil and has no use like you are trying to imply.
I can't comment on the other engine but I am familiar with Unreal Engine and this isn't the case and probably isn't the case with other engines either (Though I can't know for sure).
There are specific reasons as to why they don't use the STL (Yes I know but this is what I have been calling it and will continue to call it) in their engines and just because they are familiar doing it that way has very little (If anything) to do with it from my experience, what I have read and have been told.
Here is a link that a Epic developer responds to a question that is kinda related to this (It is about Epic using their own container implementations instead of the STL).
https://answers.unrealengine.com/questions/2695/rocket-and-the-stl.html
| Without seeing the full code, for all we know, they may not rewrite large chunks of the engine at all. They very well could have macros defined so they just change the platform flag during compilation to make builds for each platform. |
Not really sure what you are trying to say here but figured I should point out that a lot of engines now days come with complete source code. This includes Unreal Engine 4 otherwise I wouldn't have pointed out they didn't use the STL.
Last edited on
This thread came from a separate thread ( http://www.cplusplus.com/forum/lounge/127954/#msg692279 )
where Fredbill said:
As for the link, my problem with that is the fact that he starts it with:
Which to me implies he is basically saying old habits that they still feel are appropriate and then goes to listing things.
I realized a flaw in what I was talking about doing so it isn't possible without a lot of headaches so ignore that.
where Fredbill said:
| Fredbill wrote: |
|---|
| Not trying to highjack this topic or anything, but what field is that? Usually I'm told that I should learn to unlearn the STL, and that it's evil. |
As for the link, my problem with that is the fact that he starts it with:
| It's a good and controversial question. Unreal has always worked this way so there are historical reasons in play, but our programmers feel that it is still the right decision today. |
Which to me implies he is basically saying old habits that they still feel are appropriate and then goes to listing things.
| Not really sure what you are trying to say here but figured I should point out that a lot of engines now days come with complete source code. This includes Unreal Engine 4 otherwise I wouldn't have pointed out they didn't use the STL. |
I realized a flaw in what I was talking about doing so it isn't possible without a lot of headaches so ignore that.
Topic archived. No new replies allowed.
Pages: 12