Re: Removing the assignable requirement from stl list elements
Denise Kleingeist wrote:
mzaytsev2@bloomberg.net wrote:
I would like to provide example of Usefullness:
I think nobody is disputing the usefulness of putting
non-copyable and non-assignable objects into some sort of
containers. Depending on the exact semantics of the containers
there will probably be some restrictions, e.g. due to the
necessity of moving objects in non-node based container but it
should be fine to put them into a node based container.
class Mutex; // with some RAII implementation
std::list< Mutex > mutexes;
This, however, is in my opinion rather supporting the case of
*not* allowing non-copyconstructible objects into container!
What is a set of stand-alone mutexes good for? Unlike James I
don't see how this could be used reasonably for dead-lock
detection (in fact, I'd rather try to come up with schemes
preventing the potential for dead-locks in the first place)
and rather see it increasing the likelyhood of deadlocks
anyway.
Well, I also prefer avoiding deadlocks by design; detecting that
acquiring a lock will create a deadlock is generally a little
late. Still, as a form of assertion, it's useful; at least you
know immediately what's wrong. And deadlock detection requires
being able to scan the set of all mutexes, which means that the
mutex objects must be collected somehow. (Personally, I'd
probably go with some sort of container of pointers to the
mutexes, but I can imagine that an std::list< Mutex > could be
used for this as well.)
Mutex DOES NOT have copy semantic...
It better does not have, indeed.
Have Mutexes be organized, allocated and destroyed by the
container I see usefull. For example I would like to
iterate through, and check.
Check what? For deadlocks? How? At the very least you'd need
to lock a mutex for this first (otherwise any other thread
might come along and just create the deadlock you are
determining does not exist) which might create the deadlock in
the first place.
How can this lock create a deadlock?
I'm utterly unconvinced by this particular example
I've used it in practice, to find deadlocks in legacy code
(which was anything but well designed with regards to
threading). Being able to find all (or almost all) the mutex in
a given application is useful in a number of debugging contexts.
and rather see it as a counter-example. A more compelling
example would be a list of iostreams used to maintain
connections e.g. in a server application (although I would
probably use a list of stream buffers...).
And that's an example that I don't find compeling, simply
because streambuf is a polymorphic class, and you'll probably
want different subtypes in the list. Which means that you'll
need to use pointers anyway.
(Note that I don't find the example with Mutex "compelling"; in
our implementation, we also used pointers in the list, with the
Mutex constructor registering itself, and the destructor
deregistering. But I can conceive of alternative solutions
where the list would contain actual Mutex objects, which I
cannot do in the case of streambuf, because of the
polymorphism.)
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, 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! ]