You can check out but you can never leave (seem to have heard this somewhere before ho hum) You cant outrun the world, but there is no harm in getting a head start Real stupidity beats artificial intelligence every time.

:laugh: My reference was to your use of the emoticon in that message, though...

Thanks for that - the article doesn't jog my memory especially but it's smack on the money and full of super ideas. Dave Cross

Stuart Dootson wrote: Now, I'd guess most std::set implementations will have a similar level of overhead. So....I'm guessing you don't want to use std::set if you're tight on memory That is correct, at a minimum. Since each node in the set must have 2 pointers (to the left and right children of the node) at the very least (and some implementations also carry pointers to the parent node as well). If you are trying to keep your memory footprint down, vector is the way to go (assuming you have a good estimate on how many elements it will contain and can reserve that memory at some point). That said, deque will be more memory friendly if you have a lot of elements. The reasoning is fairly simple: if you estimate 10,000 elements for your vector, but end up addign 10,001, vector will try to reallocate to 15,000 elements and copy over the 10,001. With such a large memory footprint, for a few moments in CPU time, you will have more than double the required memory being allocated just to add a single element. In the same scenario, deque will just allocate another large chuck of data somewhere and add your single element in that chunk. set isn't very memory friendly. It is designed to contain unique elements that are pre-sorted for you, making it more efficient for certain types of operations, but definitely not on memory usage. If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week Zac

I'm not religious about it one way or the other. I certainly understand that one methodology will never solve every possible design problem. My personal philosophy though remains that a complex ctor made dependent upon exception handling is generally not superior to a simple "init()" call. But I am not prepared to say that it is always inferior. I have always found it very convenient to be able to return a complex object to its original default state at any point in its lifetime with an initialization function of some kind. You just have to remember that the init() cannot be virtual if you intend to use it from the ctor. "But, daddy, that was back in the hippie ages..." My twelve year old son - winning the argument. "Stan, you are an intelligent guy who responds in meaningful ways" Paul Watson 16/10/01