Personally I think stl::vector is a horribly designed mess. It pulls in
massive amounts
of garbage in the form of iterators. It has no simple way of doing
operations
like finding a matching element or inserting after an element without
using using
iterators. ::clear() doesn't release storage, and in fact there is no
member function
which does. The standard way to add something is the horribly named
"push_back()"
member. As someone who uses the stl every day for work I can say that
familiarity has breed
contempt. The more I use it the less I like it.
Perhaps the worst thing about stl::vector is that it is a gateway to the
slippery slope of the
stl and boost, a clear path to unreadable code, bloated executables,
slow compilation,
lack of performance transparency and ubiquitous use of memory allocation
and algorithms
with good asymptotic performance but horrendous real-world performance.
Take a look at:
http://people.apache.org/~jplevyak/vec.*/defalloc.h
At least it fits in a file and it addresses all the objections I have
with stl:vector.
It also supports set semantics and interconversion of sets and vectors and
'for' loops look like they should:
forv_Vec(ElemType, elem, vec)
rather than some iterator abomination.
Better yet, if you don't like something about it you can fix it rather
than living with
the problems of stl::vector and iterators.
john
On 02/25/11 11:02, Alan M. Carroll wrote:
I would like to suggest removing DynArray and replacing it where appropriate
with std::vector. This would IMHO have the advantages of using a standard
container which, frankly, is likely superior in performance, with a better API,
much better documentation, lower maintenance, and more familiar to incoming
developers.
I am not suggesting a general use of STL containers, only specifically
std::vector, which IMHO has few to none of the issues that are brought up with
regard to other STL containers. I would be willing to take point on doing the
replacement.
