Quote:Original post by herc
any obvious pitfalls visible by just inspecting the code?

I glanced over it, it looks ok.
One issue to keep in mind is that because its a stack-based array when you call erase on an element it isnt actually destructed. If you had it storing objects that were very sensitive to when they're destroyed this might cause unforseen complications, but that's not a problem with your code that's just what happens with the stack anyway.

Quote:thanks, this is great news! most of my small strings are never longer than 16 chars.

Good for you [smile]

This is why trying to second-guess the STL is usually a waste of time, its highly optimised in the first place. Just imagine if you'd spent all that time coding up a stack based string class when all you ever do is use it for 10-char strings [wink].

Quote:Original post by herc
for std::string, you people are completely right. that string class is so much more complex regarding the interface than the simple vector class. i would say that my stack based vector implementation is simpler than a custom memory allocator. by the way - do you have any comments on how i did my stack vector class? any obvious pitfalls visible by just inspecting the code?

I have the following comments.

(1) This is almost identical to the standard container designed to do exactly the same job (tr1::array, or std::array in C++09). Not surprising: it's filling the same need.

(2) One of the guidelines following in designing the standard containers was that functionality that could onlt be imeplemented poorly should not be implemented at all. Some of the functions you've carried across from std::vector can not be implemented properly in a stack-based vectorlike container. For example, resize(), reserve(), and swap(). This is why the standards committee came up with std::array: a different name for a different set of requirements and functionality.

--smw