Re: [boost] Interest in a "non derivable" utility

From: Manuel Fiorelli (manuel.fiorelli_at_[hidden])
Date: 2007-03-03 20:14:10

I thank you a lot for the suggestions and I want to say that:

   - I kept the original idea from Java Core Vol. 1 (by Cay Horstmann),
   where the author states that in C++ there aren't final classes, but they
   could be simulated through virtual inheritance....thus I tried to discovery
   that trick.
   -  there is no reason to use a protected destructor; since I use
   private inheritance, automatic conversion of pointers from the derived class
   to the base class isn't possible, thus there is no reason to prevent
   accidental delete trough base class pointers...I realized it only after the
   submission...
   - unfortunately, I just discovered that the following code compiles
   (violating the "non derivable" semantics)

struct Foo : BOOST_NON_DERIVABLE
{

};

struct Goo : public Foo, BOOST_NON_DERIVABLE
{

};

Foo foo;    // a variant or a class member
Goo goo;

I suppose it is due to the fact that the same object of class
nonderivable_helper is shared among foo and goo, thus
violating the assumption that  nonderivable_helper is not visible in most
derived classes.
I know that standard C++ prohibits template parameters and typedefs in
friend declarations, thus the only way to eliminate the problem seems to use
an ad-hoc non_derivable helper for each class, but this should require a
less clean approach:

#define final_class( class_name ) struct nonderivable_helper_ ## class_name
\
{\
friend class class_name;\
private:\
nonderivable_helper_ ## class_name () {}\
};\
class class_name : private virtual nonderivable_helper_ ## class_name

Now, one can rewrite the test as follows:

final_class(Foo)
{

};

final_class(Goo), public Foo
{

};

Foo foo;  // a variant or member
Goo goo;

and (as expected) it doesn't compile.

However, I found this technique is not convenient since:
1) it violates common C++ syntax ( what is a final_class keyword? )
2) it is not applicable to class template, which is the reason why I
definitely disapprove this solution.

I hope to find a way to enforce the library...maybe there is something
useful in Boost Preprocessor Library.

   - Can someone say me what is the reason to use a nested
   namespace....what does it mean "unintended ADL"

Best regards,
Manuel Fiorelli
www.fioreltech.net