Archived

This topic is now archived and is closed to further replies.

ThunderMusic_80

What should I use? my containers or STL?

Recommended Posts

Hi, The subject almost says it all. What should I use between my own template containers and STL if I want my project to be compilable on many OS? Because I want to build an Engine (with some friends of mine) and I was wondering what would be the best for portability and performance. Are STL performant enough so I could use them in games or are they too slow? Thanks ThunderMusic

Share this post


Link to post
Share on other sites
Yes, of course.

The world would be a better place if people would use standard libraries more often instead of wasting their own time and risking unknown bugs by implementing the same features themselves. It's okay when just for learning purposes, but if the project is at all serious...

[edited by - merlin9x9 on October 21, 2003 12:12:10 PM]

Share this post


Link to post
Share on other sites
How many platforms are you targeting? I use them on Unix and Windows (GNU g++ and Borland C++ Builder). Asking if they are fast enough is like asking if a piece of string is long enough. It depends on what you want to use it for. Write your code first, then profile it, and only after you have determined where the bottlenecks are, begin optimizing it. I'm guessing that STL vs. homegrown containers will be a performance non-issue in a game engine.


--
Dave Mikesell Software & Consulting

[edited by - dmikesell on October 21, 2003 12:05:10 PM]

Share this post


Link to post
Share on other sites
I would have to agree.

Stick with STL.

If you are going to have more than 1 developer working on your source code, it would make more sense to use a library that has been around for a while and that people already know how to use.

Plus, you also get the additional use of using such things as BOOST to enhance your template library.

Why use home grown,generic templates when you have a standard already built for you.

Personally, it is a waste of time to work on your own containers, unless you are doing it to understand the concepts behind the containers.

Alek

Share this post


Link to post
Share on other sites
quote:

It depends on what you want to use it for. Write your code first, then profile it, and only after you have determined where the bottlenecks are, begin optimizing it. I''m guessing that STL vs. homegrown containers will be a performance non-issue in a game engine.



Correct me if I''m wrong, but the STL is very fast. It was made by a bunch of really smart dudes, and If you can implement your own containers or whatever you need and acutally have them faster than the STL, then you should have no problem getting a job just about anywhere (programming I mean).
In other words, dont try to make your own in the hopes that it will be faster, unless you know an AWEFUL lot about the subject. In which case you probably wouldnt have asked this question...

Share this post


Link to post
Share on other sites
It''s fast in terms of a large project that needs flexibility, stability, and readability, but in a tight loop, the STL rarely performs better than well optimized C-style code.

Share this post


Link to post
Share on other sites
quote:
Original post by AndreTheGiant
Correct me if I''m wrong, but the STL is very fast. It was made by a bunch of really smart dudes, and If you can implement your own containers or whatever you need and acutally have them faster than the STL, then you should have no problem getting a job just about anywhere (programming I mean).
In other words, dont try to make your own in the hopes that it will be faster, unless you know an AWEFUL lot about the subject. In which case you probably wouldnt have asked this question...

Well, there''s always the chance that your needs are more specific than the STL is written for. The STL is good, but if your needs are very minimalistic with respect to the properties you need, or if your optimisation needs are very specific (the STL containers are presumably written to be efficient in terms of both execution time and storage space), I should think there''s a chance that your solution may be closer to optimal simply because your design goals are different from those of the STL designers.

Of course, for most applications, the STL should work admirably, and alternative solutions should only be researched if STL efficiency is found to be a bottleneck.

Share this post


Link to post
Share on other sites
I target everything that can run a game, so win32, macOS and Unix (linux).

I''ll stick with the stl, but what about the odd names? I mean, vector for a dynamic array, I would have searched a long time to find it alone... Is there something like a tree structure in STL?

thanks

ThunderMusic

Share this post


Link to post
Share on other sites
quote:
Original post by ThunderMusic_80
I target everything that can run a game, so win32, macOS and Unix (linux).

I''ll stick with the stl, but what about the odd names? I mean, vector for a dynamic array, I would have searched a long time to find it alone... Is there something like a tree structure in STL?

thanks

ThunderMusic

The STL appears to be written in terms of containers and algorithms rather than ADT''s; the details are often left up to the implementation. IIRC, std::map is usually implemented as a red-black tree - but this is an implementation detail. If some implementer were to come up with a better solution, they would be free to implement it. Is it not the case that the requirements placed on the STL containers are in the form of big-O runtime complexity (e.g., finding an element in an std::map is guaranteed to be O(log n))?

Share this post


Link to post
Share on other sites
quote:
...but in a tight loop, the STL rarely performs better than well optimized C-style code.

Except for std::string, this completely contradicts my experience; the STL is implemented with well-optimized code.

[edited by - merlin9x9 on October 21, 2003 3:24:20 PM]

Share this post


Link to post
Share on other sites
I''m in the minority I guess; I like writing my own containers. Honestly, I have yet to use STL, but I figure that before I should be able to use a powerful library like that, I should at least know what''s going on. It''s kind of like in calculus... when you''re first introduced to the concept of a derivative, you have to use the definition to solve the problem. You gain some understanding, and eventually, you are allowed to use shortcuts to take derivatives, and you really appreciate the shortcuts. Kind of similar, IMO. I think every coder should be able to at least program any container, if not as fast or bug-free as the STL.

Share this post


Link to post
Share on other sites
Sure, you should be able to write your own container classes. You can do that in CS 102, while following the exercises in the textbook. And then you toss that code out--or perhaps save it as a curio--and use the STL.


How appropriate. You fight like a cow.

Share this post


Link to post
Share on other sites
Again, I may be mistaken, but I * believe * that the actual implemetation of the STL is up to the people writing the library for any given C++ compiler. Therefore, there is no guarentee that having one class (say std::string) that performs very good will perform on all platforms (but will perform the same if the same compiler is used.)

Regardless, one problem that may come into play is there are some "uncertanies" that can come with the STL, or times when it doesn''t give the functionality you want. (unforuntatly it''s also hard to extend unless you know the internals of the implementation.)

Share this post


Link to post
Share on other sites
I don't know about you guys, but with the textbook I started using, Accelerated C++, it had me using the STL right from the very beginning. I can now also see why true professionals highly regard that book. Why reinvent the wheel in most instances?

[edited by - nervo on October 21, 2003 4:16:06 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by UberGeek
Again, I may be mistaken, but I * believe * that the actual implemetation of the STL is up to the people writing the library for any given C++ compiler. Therefore, there is no guarentee that having one class (say std::string) that performs very good will perform on all platforms (but will perform the same if the same compiler is used.)

Maximum time-complexity of all STL functions **IS** part of the standard. That is, you know the big-O time for each function.

quote:
Regardless, one problem that may come into play is there are some "uncertanies" that can come with the STL, or times when it doesn''t give the functionality you want.
You''re free to provide an example here. Many times, such alleged lacks of functionality are actually just an incomplete understanding about how to use the STL.


How appropriate. You fight like a cow.

Share this post


Link to post
Share on other sites
quote:
Original post by Sneftel
Many times, such alleged lacks of functionality are actually just an incomplete understanding about how to use the STL.



Or from using the library that ships with MSVC 6.
If it''s your case, go download STLPort.


[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | C++ FAQ Lite | Function Ptrs | CppTips Archive ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Free C++ IDE | Boost C++ Lib | MSVC6 Lib Fixes ]

Share this post


Link to post
Share on other sites
Last time I measured STL vector performance in dinkum''s implementation it outperformed my own vector class. Then I switched to SGI and that outperformed dinkum''s. STLport is based off of SGI code so it''s fast. I use STLport and no problems so far. The problem with writing your own stl is that you need to study a lot of algos and know a thing or two about optimizations. All this takes extra time but it''s doable. If your main emphasis is on other topics than stl then use the tools and don''t reinvent them. How would it be if everyone had to write their own os/lang. tools before they got into 3d gfx. Pick your area of interest and work on that.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I guess im the only one who [would be]/is stupid enough to reinvent the wheel, mainly ive written my own "containers" cause of the ugliness of stl, i mean its a very ugly library in my opinion.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
ap from above.

quote:

Correct me if I''m wrong, but the STL is very fast. It was made by a bunch of really smart dudes, and If you can implement your own containers or whatever you need and acutally have them faster than the STL, then you should have no problem getting a job just about anywhere (programming I mean).
In other words, dont try to make your own in the hopes that it will be faster, unless you know an AWEFUL lot about the subject. In which case you probably wouldnt have asked this question...



If thats the case then I should have a job!

Share this post


Link to post
Share on other sites
quote:
Original post by merlin9x9
quote:
...but in a tight loop, the STL rarely performs better than well optimized C-style code.

Except for std::string , this completely contradicts my experience; the STL is implemented with well-optimized code.

[edited by - merlin9x9 on October 21, 2003 3:24:20 PM]


I just finished writing a Turing machine for a school project. Same code, one using an STL vector (gcc 3.2.2) the other using an array and pointer arithmetic (good since the tape head only moves one square at a time) was on the order of 10x faster in the tight loop. Profiling the code brought to my attention that every call to operator[](int) incurred a call to *(const_iterator), which brought with it far more instructions than *p ever will.

Like I said, in a tight loop (one where you care how many instructions are actually executed), the STL usually won''t be faster. And in my case, on large inputs that traversed the tape in both directions, it was several minutes slower.

Share this post


Link to post
Share on other sites