Re: std::string bad design????
Tony wrote:
I've been back and forth in my thinking on that so many times over the
years.
You should try the iterators-state-in-the-container model. Everyone I
have met who has experience the pleasure of not having to create an
iterator to go with a container has raved about it, from students to
colleagues. It's addictive, and especially attractive when you are
iterating over a container that is 3-levels deep inside nested
containers.
But I digress. I don't think it's so much that the iterators-and-algos
approach is hard to grok, but rather that there's few algos that aren't
container-specific. I've been through the whole "derive from a
ForwardContainer class, which is derived from Container etc", and
that doesn't work out too well at all (though it can be done). But
conceptually, I think that's what they were thinking when the
iterators-and-algos brainstorm hit someone(s). I wonder if that
represents some kind of failure of recognizing (read, not yet found)
the "right" solution to the problem. But then that is what you both
are implying maybe.
I think the STL people got carried away. IMO, the most blatant wart,
aside from letting iterators be external to containers, is the notion
that all containers are linear, in the "movement" of the iterator is 1
dimensional. But trees are containers, very useful containers, and we
do not have a tree<> template in STL. I suspect that the reason we
don't is because it would illuminate the fact
algorithms-are-universally-applicable model is not so universal, and
that containers do not all fall under the linear model. A tree<> will
resist push_back() immediately, for example. It simply does not make
sense.
These are two of the reasons I do not use STL containers.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]