Not Using STL is good because...

[imaxx]

Today I did run in a funny issue in my work (let's say an engineering team in a cool company in a cool project).

I won't enter details, but it all ended up to this, said by a 50yr SW engineer:

For portability issues you should never use STL - you should write your own code. I trust more my code (than STL one)

...just wanted to share with you all, it would have made my day if it weren't happening to me...

 

[Davros]

Today I did run in a funny issue in my work (let's say an engineering team in a cool company in a cool project).

So we can rule microsoft out

 

[PixResearch]

Warning treated as error: STL has been deprecated.
Please use STL_s

 

[Humus]

For the record, STL has portability issues. Some stuff behaves different on different platforms. Not necessarily in a way that is out of spec, but implementations vary and certainly performance characteristics. A typical example is calling std::vector.clear(). Some implementations will free the memory, some will merely set the size to zero retaining all allocated memory. To really make sure it frees the memory you have to write some really ugly code, e.g.: http://stackoverflow.com/questions/3172699/is-this-normal-behavior-for-a-stdvector

If you have your own code, you have full control. You can free or retain memory as you please. You have a choice in exact algorithms and memory allocation schemes. Depending on the needs of your cool project in the cool company, this may matter quite a great deal. Certainly for game development these factors typically outweighs any perceived benefit of STL. For us, the use of STL is generally discouraged within the company. Of course, there are bits and pieces in there that makes sense for us too, like std::sort(), but using for instance an std::vector is rarely the right thing to do. Our own Array class on the other hand will behave exactly as we implemented it on all platforms.

 

[McHuj]

Today I did run in a funny issue in my work (let's say an engineering team in a cool company in a cool project).

I won't enter details, but it all ended up to this, said by a 50yr SW engineer:

...just wanted to share with you all, it would have made my day if it weren't happening to me...

I agree with him.

 

[ERP]

We avoid it, and I know a lot of places where using STL is against the coding standards.

If you don't care about the implementation it's fine for what it is, IME the STL implementation is rarely what you actually want.

 

[imaxx]

I agree with him.

This is really interesting - can you tell me why? A good reason to use your own list/tree instead of ready-made and tested ones.

As long as you don't have issues with:
* best possible speed, to death like i.e. vgame development.
* embedded devices (where even a full clib would be a problem).

@Humus: agree, for example ANSI doesnt say anything about i.e. going before begin iterator. Yet, what makes you think your code is better tested and stabler than STL one?

 

[McHuj]

This is really interesting - can you tell me why? A good reason to use your own list/tree instead of ready-made and tested ones.

As long as you don't have issues with:
* best possible speed, to death like i.e. vgame development.
* embedded devices (where even a full clib would be a problem).

@Humus: agree, for example ANSI doesnt say anything about i.e. going before begin iterator. Yet, what makes you think your code is better tested and stabler than STL one?

Funny you say that, because the two issues you mentioned are my issues.

The main reasons are speed in embedded applications and full control over the code/implementation. Now, I'm not coming from the video game world, but a DSP one where performance to handcounted cycles is king. But even then, some times our code needs to execute on a non native platform like x86 where realtime speed isn,t an issue, but it would would be, imo, to cumbersome to maintain two implementations of code (one STL and one not) to enable that.

 

[3dcgi]

A lot of people seem to not like STL, but Humus is the first I've casually run across that gave a specific reason. Most people just say it's too slow. That might be true for some cases and there are a lot of people here with more programming experience than I, but there are many applications that won't have a performance issue with STL and will benefit more from increased productivity.

I use STL extensively in a database application that runs on Windows and Linux and while it's possible memory isn't being handled the same way I've never noticed any functional difference in my program.

 

[epicstruggle]

A lot of people seem to not like STL, but Humus is the first I've casually run across that gave a specific reason. Most people just say it's too slow. That might be true for some cases and there are a lot of people here with more programming experience than I, but there are many applications that won't have a performance issue with STL and will benefit more from increased productivity.

I use STL extensively in a database application that runs on Windows and Linux and while it's possible memory isn't being handled the same way I've never noticed any functional difference in my program.

Don't use STL either, but that's mainly because I work in a assembly-like language where we dont have it.

 

[Ethatron]

Writing your own allocator should overwrite black-box allocator behaviours, I think.

 

[itsmydamnation]

so then..... what should someone learning c++ do, everything i have touched pretty much uses STL whether its string or console in/out etc. As a hack do i just continue using STL or at what point is it worth building your own library of functions/data types etc.


cheers

 

[Rodéric]

I used stdint.h from C99 for types, and std::string (lazy ) + std::vector (in tools).

Ill defined spec, not playing well with serialization are two reasons to avoid STL.
(Barely readable errors don't really help either.)

A lot of programmers like short readable code, STL just doesn't fit.

 

[McHuj]

so then..... what should someone learning c++ do, everything i have touched pretty much uses STL whether its string or console in/out etc. As a hack do i just continue using STL or at what point is it worth building your own library of functions/data types etc.


cheers

I think you should learn STL. It's important to know. But it's kind of a judgment call when to use STL or not that just comes with experience.

 

[epicstruggle]

I think you should learn STL. It's important to know. But it's kind of a judgment call when to use STL or not that just comes with experience.

STL can make you lazy, I like to get my hands dirty and code most of what I could get for free with STL. Comes with risks, but you get to understand how things like memory allocation happen and where pitfalls can arise.

 

[Gubbi]

IMO, the STL container templates has great utility. Probably not fit for hardcore performance kernels.

Cheers

 

[AlexV]

so then..... what should someone learning c++ do

cheers

Focus on learning it and on those who teach it. Then you can move on to the grey area of quirky worries. There is a reason for which most books trying to teach usable modern C++ use the STL quite a bit, and it's not because the guys writing them are evil.

 

[Ethatron]

Right. And you can program rather quick complex things, which is good when you come from high level languages and don't want to be bothered to implement every quinch of a simple common data-structure. If you need to start to be worried about specific aspects of a STL implementation (performance, compliance, etc.), you have become a pro anway. So learn it, use it, and judge it by it's utility value in time.

 

[Humus]

Writing your own allocator should overwrite black-box allocator behaviours, I think.

Default allocators are typically just wrappers around new and delete anyway. But even with a custom allocator, you'd still have the problem I mentioned with clear(), because an implementation that retains the memory wouldn't even call into your allocator. If you're a game developer, the std::vector clear() issue can matter because Microsoft's and Sony's implementations do this differently. I don't remember which one did what, but this was an issue we ran into at one point.

Another problem with std::vector is of course that every push to it will check capacity and potentially resize. Normally you know ahead of time how many items you will need, so for performance reasons it's better to just set capacity upfront and then fill it in. This pulls capacity checks and allocations out of the inner loop. Also reduces memory fragmentation.

 

[Npl]

But aint this something you can easily replace at any time? I think this is STLs biggest strength, once you seen through the design choices, you can take your own vector class or template and use it everywhere.
you arent tied to specific classes.

STL is a great thing to get going, the rest is something you can solve when its necessary