Saturday, April 22, 2006

To STL or not STL...THAT is the question...

I spent yesterday afternoon chatting to Russell about templates and the standard library stuff, and have almost found what I was looking for; a reason to use it. Templates are very nice at giving a standard interface to multiple objects via its iterators, and from someone that writes API's for others to use, I like that - even though I don't yet like the code you have to use. But, you get used to these things, and so I started talking to Russell about templates, and he suggested doing some simple linked list stuff. Good idea.

So, here I am at home playing with linked list templates and trying to figure out what STL is all about. Its odd really, to be good at your job you have to be able to do things properly, an quickly. But whenever you have to learn something new, one half of that won't be true anymore. You'll either do it quickly and wrong, or slowly and right. This is one of the things that grates me about learning new stuff, particually something as complex as templates. Yes, the basics of templates are easy enough, but to get the best use out of them, you have to be more clever than that.

STL is a case in point. when you decided you want to include a list, its easy enough: list< class > var;. And your done. And this is usually as far as most programmers get. But I'm not most coders, I want to understand whats going on under the hood to see why I should use STL, rather than just being told its a good idea. And under the STL hood, theres a demon waiting to escape - its horrible. From this, I can now see why windows slows down with each iteration, and it frightens me that most coders just dont know what its doing, burning away your time and memory without you realising it.

A small example... everytime you decided to "push_back()" a new object, you have to figure in a few more things.

1) You're allocation of the object itself.
2) a small class that now links the objects together. (around about 16 bytes for a list)
3) 2 memory block headers that malloc() will allocate for each bit of memory you've allocated.
4) a Critical section In/Out each time you add (I'm guessing this is an implementation detail that some might not use, and possibly only in debug as well - I've yet to find out).

Thats a hell of a lot of work to add a link. If your dealing with thousands of links (or tens of thousands) then this is slow and memory consuming work; and most programmers will never understand why. In the C++ book there are 2 very good bits of advice. 1) Don't reinvent the wheel, and 2) Don't believe in magic, understand the libraries and what they do, and how.

Good advice.

No comments: