Quote:Original post by swiftcoder
Yes and No, STL is implemented primarily for reliability
no it isn't just that.
Quote:Original post by swiftcoder
(i.e. extensive exception checking)
Where the only operation i think of that throws an exception is vector's at method, STL containers are written with exception safe code.
Quote:Original post by swiftcoder
, and I'm afraid that speed sometimes suffers.
That would be your user-defined type's fault not STL containers, blame it on your written or implicitly defined copy constructor's so slow initialization for that.
Also blame it on irresponsible usage & lack of thought.
Quote:Original post by swiftcoder
If you write a simple list or vector implementation, with just the basic functions, you can reliably find 10-15% speed gains.
yes gain 10-15% speed gains for schematically incorrect/silly behaviour.
Lets make a scenario shall we, lets say we write a hand made list we have an operation that lets you add elements to the list we decide to try and be more efficent so we store pointers to the instance.
Okay fine we begin to use this list in some function some where we add an element that was declared in the scope of that function, opps you have dangling pointer syndrome when the function's scope is ended, another thing is you cannot use this operation on literals.
Okay we make some changes the list now passes by
constant reference and then copy constructs the instance on the heap and adds it to the list this deals with both isssues. Oh Wait a minute thats what standard library containers do already oh well....
And before anyone says that they would use something else other than the generic memory operators new/delete or a different memory model well that is an invalid arguement because you can use custom allocators.
Quote:Original post by swiftcoder
However, it doesn't supply those convienient std::out_of_bounds exceptions :(
only method i can think that does that is the "at" method of vector.