RE: [boost] Documenting non-copyable-ness (was: Re: Review: Boost.Threads)

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-09-04 10:09:20

----- Original Message -----
From: David Abrahams <david.abrahams_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, September 04, 2001 11:07 AM
Subject: Re: [boost] Documenting non-copyable-ness (was: Re: Review:
Boost.Threads)

>
> ----- Original Message -----
> From: "Fernando Cacciola" <fcacciola_at_[hidden]>
>
> > The current concern is that every noncopyable class is rooted at
> > 'noncopyable', that is, a *single* and *uniquely identified* class:
> > noncopyable.
> >
> > Consider:
> >
> > class Foo : noncopyable {} ;
> > class Bar : noncopyable {} ;
> >
> > Those two classes are *completely unrelated*, yet they belong to the
same
> > hierarchy.
> > This fact -the conceptually wrong hierarchical relation between them- is
> > messy and a very subtle source of problems; even though most
applications
> > will hide this.
>
> Aww, c'mon. Have you ever had a problem due to a shared /private/ base
class
> of unrelated classes?
>
Don't get me wrong. I am not saying that this is a serious problem that has
to be fixed. I was just wondering why isn't the idiom used while it is
harmless and achieves the same effect.
I've never had any problems because of this, of course. Except that my class
browser is pretty unusable mainly do to this.
But never mind.
Though I note the existence of the idiom. Perhaps it can be used in
subsequent developments of similar cases.

 > Messy because in a graphical class browser everything is rooted at
> > noncopyable.
> > Error prone (very subtle) because, as it was expressed, one can manage
> both
> > classes through a noncopyable*.
>
> How do you acquire such a pointer?
>
Correct me if I'm wrong, but I thought Peter explained that a C cast would
allow to acquire such a pointer.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com