Sign in to follow this  

STL efficient in size?

This topic is 3861 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've always steered clear of STL in my applications because I believed they were bloated and sluggish and reading around lately I'm starting to come around and believe my old view was rather naive however I'm still suspicious. I'm currently developing games for mobile phones and code size is a big issue obviously and I'm just wondering how STL would suit in these situations. Things like std::string vs char* and standard arrays like int[] vs std::list etc, is there much of an overhead in not only code size but also memory footprint etc? My guess is that the STL might be optimised for speed but standard types would be better for keeping size optimisations?

Share this post


Link to post
Share on other sites
STL or SC++L doesn't imply implementation, just the concepts, behaviour, and certain contracts.

Your implementation might be bloated, or it might not be.

Many constructs compile with no overhead, some are not so efficient - STL is general purpose.

From algorithmic perspective it's somewhat optimal. But especially for embedded it might not be.

But most importantly, STL is not a 600lb gorilla, despite the scary template syntax and somewhat expressive syntax. Iterators over arrays compile into the same as for loops, iterators over custom containrs are bulkier, but do not incur much performance overhead (no more than you would if you re-coded it).

But if you're looking for leanest meanest library - there is no such. It all comes down to what is acceptable for your needs.

For mobile phones? I don't know. For most general purpose cases, there would be no difference, with exception of likely much safer code. Whether it's a viable trade-off depends mostly on you.

Share this post


Link to post
Share on other sites
It depends on the std types you use. std::vector typically uses only an additional size_t for the length of the array, something you would have to do yourself anyway in most cases. std::string often stores a size_t for length as well, which is overhead if strings are null terminated anyway. std::list is doubly-linked, so you may need your own singly-linked list, but it typically forgoes caching the length to save storage space.

So all in all, not so bad for space, as long as you don't use the wrong container.

Share this post


Link to post
Share on other sites
Thanks for the replies guys. I wasn't sure how it all compiled down in the end. Something that was irking me a bit was in some of the code we use here theres a custom array template that seemed to be using a huge amount of overhead. I haven't had a look at the implementation yet, I wasn't sure if the templates compiled down to something unusual, but it sounds like the implementation here may be a little... bloated.

Share this post


Link to post
Share on other sites
I've read of an STL implementation that only compiled the various algorithms once, and only added a tiny bit of overhead through wrapper templates for each different type it was instantiated with, or something like that.

Can't remember where I found it though sorry.

Share this post


Link to post
Share on other sites

This topic is 3861 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this