Friday, February 25, 2011, 4:27:01 PM, you wrote:
> Personally I think stl::vector is a horribly designed mess.
> [...] It has no simple way of doing operations
> like finding a matching element or inserting after
> an element without using using
> iterators.
std::vector<A>::iterator spot = std::find(TheVector, TheValue);
if (spot != TheVector.end()) { ...}
doesn't seem worse than
int i = 0, n = TheDynArray.size();
for ( ; i < n ; ++i )
if (TheDynArray[i] == TheValue) break;
if (i < n) { ... }
except I can't mess up the iteration. Not to mention it doesn't do an offset
calculation every iteration.
> ::clear() doesn't release storage, and in fact there is no
> member function which does.
TheVector = std::vector<A>(); // release storage.
I have to say that I've never encountered a situation where that was useful.
Either it's basically permanent, or it's part of a structure which gets
deallocated thereby freeing the storage (e.g. ControlBase for TS-674).
> The standard way to add something is the horribly named
> "push_back()" member.
Not the best name, but I think better than the function operator.
> Perhaps the worst thing about stl::vector is that it is a gateway to the
> slippery slope of the
> stl and boost
I think that's probably the strongest argument.
> 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.
Where's the base class gc?
> 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.
What's wrong with iterators except the type names are longer? At least you
don't have to worry about whether the index is int, unsigned int, size_t, etc.
> 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.
After living with std::vector for a decade or so, I haven't really found it to
be a problem. Possibly less of a problem than having to learn new container
classes for every project and having random committers "fix" fundamental
containers.
That said, I would be fine with that class if
* The defines were removed (those have given me far more problems over the
years than iterators)
* Doxygenation
* A few typedefs (e.g., "typedef C element_type;" so templates can reach in
more easily).
It's certainly far better than DynArray.
