STL is very important for almost any C++ programmer. I'd hate to write ten lines of C++ without having access to STL, and I'd take STL over inheritance and virtual methods any day.

That beeing said, just a couple of years ago many compilers gave som pretty useless error feedback when using STL. And the initial decision of not having hash-map in the first version was an annoying dissapointment.

Stroustrup is correct. STL is one of the rare libraries which is both robust, flexible, and efficcient.

Quote:Original post by VprMatrix89

I really want to know how important is the stl in REAL games?

A carpenter comes to fix your ceiling. You see they don't use a hammer, but take off their shoe, and use that instead.

Upon asking them, they say they don't care about hammer, because they are overhyped. He then proceeds to show you the double reinforced heel of the shoe, along with padding on the sole, supposedly to improve the grip.

Quote:Especially things like cin and cout , are they even used?

The difference between std::c* approach and *print*(...) approach exists. There are trade-offs, and in some cases, the later may be preferred. But this again is a matter of case-by-case requirements evaluation. Knowing both approaches well, and being able to recognize the most suitable one is well recommended.


One thing that always boggles my mind, is for engineers to deliberately refusing to learn as many tools at their disposal as possible. Script kiddes - fine. But anyone aiming above that should:
- Look at (in this case very fundamental) technology
- Evaluate it in context (open source, articles, books, case studies)
- Apply it or dismiss it, based on requirements of a project

And hopefully, nobody attempting to work on "real games" will find a tiny little set of classes that are STL intimidating. That in itself is a much bigger problem.

Quote:My guess is that the stl's string, vector, and map are just dressed up arrays with functions to help out.

No, they're not. Guessing here is somewhat pointless, STL is very precisely defined, and it's not about dressing up. It tackles some crucial issues that deal with the difference between C and C++ way of doing things, as well as addressing some big issues that C++ is known to have.

Quote:Original post by MaulingMonkey
"The SC++L is fast" is 1 reason why, but it admittedly doesn't go into the details. Aside from strict algorithmic performance requirements set forth by the standard, modern implementations use a huge bag of tricks to perform at their best -- empty base optimization, return value optimization, tag based dispatch to optimized versions, and general tailoring to the compiler they're targeted for. It's very intentionally designed to be damn hard to beat for the tasks they're designed to solve.

Actually, they are not. At least on my GCC 4.3, that's it. My own std :: vector implementation is a whooping 70% faster than the STL one. But remember, unless you use a given STL container very heavily in your code there is absolutely no reason to reimplement it, since, as MaulingMonkey said, the STL containers are already debuged and basically bug-free. It's silly to introduce new bugs in your code when there will be no benefit performance-wise.

So there we are again, the same old question keeps rotating around the same point viciously.

Well STL is, as a standard, certainly well defined and has a very concrete goal. But to be honest, when someone says "STL containers and algorithms will be as optimum as possible", I'm sorry to note but this isn't always the case. And I wonder to which STL implementation iD's code is compared? Because, there are many implementations, one can run faster or slower than the other. So, saying that STL will be always optimum and at least as fast as custom code, is pointless... You can say "libstdc++' STL implementation will be..." but it would be one huge mistake if one generalizes all of the STL implementations out there.

Also have you checked Dinkumware's implementation? One big pile of pointless indirections. Though, according to the ASM output, the compiler is somewhat successful at handling it.

STL sure provides a very nice fundamental for building on top. But in my opinion a good coder should also know what he/she is using. It's true that coding more complex applications became very easy with the adoption of STL use in the projects, though we also started to end up with "coders" who doesn't even know why they are calling certain functions or why they are using a certain container X for the task Y.

I'm not advocating STL nor doing the contrary. Yes trying to code something similar would certainly be re-inventing the wheel. But why not, if I can? Please note that what I say applies mostly to the indies or amateurs like us. Most of us have nothing to lose but time while doing so, unlike big companies with millions of dollars to sink, thus in the end you would learn what you're calling when you call array.clear(); Also it's a very nice practice to code such things.

So, to use STL or not, it depends on your intentions as a coder. I, personally, would love to take the challenge and write something similar just for my personal use to see how far my abilities and skills can carry me in a race with all those big sharks in the ocean.

Quote:Original post by desudesu

Actually, they are not. At least on my GCC 4.3, that's it. My own std :: vector implementation is a whooping 70% faster than the STL one.

So it can do Kessel run in 12 parsecs?

What does 70% faster mean in terms of vector?

And a very important point that is missed by previous sentence: On GCC 4.3. STL containers guarantee behavior on STL-compliant implementations. Regardless of compiler, regardless of platform.

It's a fact that sequential storage can be implemented in a different way, one which has lower constant factor costs. That is not why STL came to be.

Quote:It's true that coding more complex applications became very easy with the adoption of STL use in the projects,

It's the very big projects which may, if possible, justify creating your own containers.

But what is the purpose of writing 5000-line implementation of your own standard library for a 2000 line project?

I'd be very wary of someone implementing STL equivalents in under 40 man-hours that even approaches the quality of current STL implementations. And that is a lot of money for mere constant factor improvement. Some do that because they really need to, or because they don't have a choice.

And besides, 70% improvement is mostly moot point, when simply using the facilities provided by STL can provide 50x (fifty times) faster usage.

Quote:Original post by Omid Ghavami
I'm very skeptic to your numbers without source and compiler settings for your benchmark. And 70% faster at doing what? Access? Insertion? Deletion? You are being extremely vague.

Sorry for being vague. Insertion. Access is obviously irrelevant here (constant time). Deletion (of the first element) is about 800 thousand % faster, since I managed to get away without memory reallocation every delete. My std :: vector probably doesn't exhibit *exactly* the same behaviour as STL one, but, I don't care. That wasn't my design goal. I wanted a vector that, speed-wise, can be used in a place of massive raw array manipulations without (or with very negligible) performance loss.

Quote:Original post by Antheus
It's the very big projects which may, if possible, justify creating your own containers.

But what is the purpose of writing 5000-line implementation of your own standard library for a 2000 line project?

I'd be very wary of someone implementing STL equivalents in under 40 man-hours that even approaches the quality of current STL implementations. And that is a lot of money for mere constant factor improvement. Some do that because they really need to, or because they don't have a choice.

That's what I was saying in my previous post, unless you really need the speed (or have too much time on your hands), there is no point in doing the reimplementation. On other hand, when you need it you don't have to reimplement the whole STL - one can always rewrite a given container, or even rewrite it only partially, excluding the features that will not be used.

Quote:Original post by desudesu

Sorry for being vague. Insertion. Access is obviously irrelevant here (constant time). Deletion (of the first element) is about 800 thousand % faster, since I managed to get away without memory reallocation every delete.

So you have ultra-special case which you optimized. That doesn't make it faster.

Quote:My std :: vector probably doesn't exhibit *exactly* the same behaviour as STL one, but

Then do not compare it to that. And how did we get from 70% to 800,000% over a single post?

Quote:That wasn't my design goal. I wanted a vector that, speed-wise, can be used in a place of massive raw array manipulations without (or with very negligible) performance loss.

Then do not claim std::vector is slow, when it's your algorithmic requirements that are the problem. std::vector is storage class, with well-defined characteristics. Using it for a task that it isn't suitable for will make it "slow".

State that you required O(1) deletion of first n elements in combination with contiguous storage, something that std::vector isn't designed to do.

The by far obvious solution for this is what you came to - advance the front pointer rather than delete.

Quote:Original post by ToohrVyk
With a few corrections....

Quote:Deletion (of the first element) is about 800 thousand % faster, since I managed to get away without memory reallocation copy every delete.

I'm wondering if you haven't just reinvented std::deque [smile]

Quote:My std :: vector container probably doesn't exhibit *exactly* the same behaviour as STL one, but, I don't care. That wasn't my design goal. I wanted a vector that, speed-wise, can be used in a place of massive raw array manipulations without (or with very negligible) performance loss.

It's been a long-known fact that some containers will outperform a vector on some operations. For instance, std::deque and std::list generally outperform a vector when removing or inserting elements at the front. This is less a case of "the SC++L is slow" than a case of "using the wrong container is stupid".

Not really. I did the research. Insertion in std :: deque is still 49% slower than my implementation. Deletion of the first element is still unbearably slow. (Several thousand %)

Quote:Original post by Antheus
Then do not claim std::vector is slow, when it's your algorithmic requirements that are the problem. std::vector is storage class, with well-defined characteristics. Using it for a task that it isn't suitable for will make it "slow".

State that you required O(1) deletion of first n elements in combination with contiguous storage, something that std::vector isn't designed to do.

Probably. But it is designed for fast insertions, for which my implementation is still faster. You can treat my constant time first element removal as a 'bonus'.

And, where did I say that std :: vector is slow? I'm just saying that it is not as fast as using a plain C-style array.