Re: std::string bad design????
"Le Chaud Lapin" <firstname.lastname@example.org> wrote:
Mirek Fidler wrote:
Le Chaud Lapin wrote:
Most of my containers
(non-tree) have indexing operations using unsigned int as the index, so
What is the point of maintaining internal iterators then?
The best I can say is that, for me, it creates the right "mood" when
using the containers.
For example, let's say you have a map, that maps names to telephone
Associative_Set::<String__, Phone_Number> phonebook;
// Add several entries to phonebook.
, and I want to change the telephone number of "Le Chaud Lapin".
Instead of having an "update key value function", I first "locate" the
row that contains my name, then assign to the right-hand-side of the
phonebook.locate("Le Chaud Lapin");
phonebook.RHE() = "08 70 35 19 38";
Others have objected to the above based on threading issues, I'm not
sure that is relevant since C++ doesn't have any standard threading
model, but I have a different objection.
Your phonebook object has internal state that the user of the object
must know in order to use it correctly. In other words, I can't call
RHE() without first checking, or otherwise knowing, that the internal
marker is in the right place. I call that poor encapsulation.
Now I grant that iterators also have poor encapsulation (I have to
check, or otherwise know that the iterator is not equal to the end
element before dereferencing it.) But I see no reason to call your
solution any better when it has the same problem.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]