Re: std::string bad design????
Le Chaud Lapin wrote:
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.
It's easier for the author of the container, yes. On the other
hand, I've never found a user who had to use one who didn't end
up cursing the author of the container for it. How do you
maintain several iterators into the container, for example.
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.
I'll agree that they sort of got carried away. Random access
and iterator are an oxymoron, for example. (In fact, random
access is a property of the container, and algorithms which
require random access should be passed a reference to the
container, and not iterators.) An iterator does imply
sequential transversal, however---at least, that seems part of
the definition of the word to me. Which doesn't mean that
trees aren't valid types of containers; just that they may
support several different iterators (with different orderings),
and that (probably more significantly) iterators aren't the
appropriate means of accessing them in all cases.
These are two of the reasons I do not use STL containers.
That's sort of biting off your nose to spite your face, isn't
it. The standard provides a number of eminently usable
containers, which have the enormous advantage of being standard
(and thus, by definition, known to anyone knowing the language).
Obviously, they don't do everything, but no other alternative
would, either. If I need something really special, I write it,
but most of the time, std::vector, std::string and std::deque do
the job more than adequately, regardless of what I might thing
concerning some of the details of the design. Similarly, I make
rather intensive use of std::map, even though if I had to write
my own, I'd use a hash table.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]