Re: std::string bad design????
Diego Martins wrote:
Le Chaud Lapin wrote:
, 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
located element:
phonebook.locate("Le Chaud Lapin");
phonebook.RHE() = "08 70 35 19 38";
std::map has essentially the same thing using operator[], but there is
no memory of where the marker lies. And as far as the multiple
iterators situation, that is extremely rare in my code. I might use it
in GUI development, for example, then even then, I must use keys
instead of iterators because of the well-known GUI snapshot problem.
what about thread safety? :-(
Hi Diego.
My containers provide the same thread safety that you wold expect from,
say, map<>: none. I have never used STL containers, but I would
imagine that iterators can become invalid if one thread, for example,
completely depletes the container while another thread is not looking
:)
And I love this. I love that I can compose a container to a
thread-safe container if that is what I need at a particular moment,
and have one that is not thread-safe if that is what I need at that
particular moment.
Here is some real code with and without thread-safety:
With Thread Safefty:
Shared<List<const Event *> > events_for_changed_multicache;
Without Thread Safety:
List<const Event *> events_for_changed_multicache;
I guess you can infer from this post that, no, I do not believe it is
appropriate to make objects thread-safe at the object level in general.
I think it is better to compose that which you want. I am following
this principle _not_ for performance reasons. It is because I believe
that it is congruent with minimalism, analysis, synthesis, and
composition.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]