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