Re: std::string bad design????
Seungbeom Kim wrote:
Hi Seungbeom,
Now, imagine several threads calling locate() and RHE() on the same
phonebook to retrieve phone numbers of several people, without any
modification at all. You have to make sure that no other threads
intervene between the two calls in a thread, or the output will be
meaningless.
You mean like this?:
multicache.acquire();
if
(multicache.targets_of_termination.locate(targets_of_termination.LHE())
&&
multicache.targets_of_termination.RHE().locate(targets_of_termination.RHE()))
{
multicache.targets_of_termination.RHE().remove();
if (multicache.targets_of_termination.RHE().is_empty())
multicache.targets_of_termination.remove();
}
multicache.release();
This is real code for a real system has at the very minimum 11 threads,
and could scale up to 80 threads. I make two claims:
1. This code will never have any threading issues.
2. Not once, in my dull life, did I ever expect two threads to be able
to operate on (what is effectively) a single global variable, and not
have to worry about contention. I am utterly perplexed that other
people seem to expect otherwise.
Note that this code is surrounded by two peculiar statements:
multicache.acquire();
multicache.release();
That's how I know it is thread-safe.
Recall that there are even cases where many standard functions that had
internal states such as strtok() and the localtime() family are being
replaced by the thread-safe versions that take external states, and what
you advocate is exactly the opposite.
First, local time cannot get the time entirely from internal state
(obviously). Second, I have never used strtok, but I would guess that
it has something to do with taking tokens from a string. I have a
class that is effectively a compiler that takes the grammar of a
language as one of its arguments, arguably more complicated that
strtok. Not once did I feel compelled to maintain global state. If
the designer of strtok decided to using external state with
spin-locking and/or mutual-exclusion, more power to him. The only
reason I can think for doing this is to keep track of next place to
start looking, and perhaps a few other things. But if that is the
case, the the fact that the operation itself _requires_ state is
staring him right in the face, which means, a object-based approach
might be more appropriate. If one argues "but it has to be compatible
with C", I would say, "Do not delude yourself. You either have state,
or you do not. If you do, then either have the caller supply the state
on every invocation, or use global variables and accept the
consequences."
And you cannot have more than one iterator per container. You say it's
extremely rare, but I would say not. Consider a simple task of finding a
duplicate phone number in O(n?) comparisons, for example. It's almost
impossible (or very difficult) with your design.
That is a function of the data structure and has nothing to do with my
iterator model. How fast does map find duplicate values?
map<int, double> foo; // How fast does map<> find duplicate doubles?
And you have to give up using constness in such a container, because
just retrieving data results in an observable change in the state of the
container.
That is part of my interface definition. I can have a const container
and a non-const container. The const container provides a contract
that states that no elements can be added, removed, or modified. The
non-const container provides a contract that says all operations are
permitted. In the non-const container, the iterator can still move
around inside because it has been declared mutable.
Anyone who uses my container is fully aware of this contract. What is
more important is that, after using it, they have all agreed that they
willfully accept that the iterator can move in a const container,
meaning, they like the "feel" that the container yields. If anyone had
come to be and said, "You know, I like your containers, but that
iterator being allowed to move around in a const container really
irritates me", I would have taken it out or done something else. What
100% of the programmers who have use these containers have all said is
that it pleasurable to have the iterator on the inside.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]