Re: No Leaf
On Feb 13, 11:39 pm, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
James Kanze wrote:
On Feb 13, 10:46 am, jrwats <jrw...@gmail.com> wrote:
So a common pattern in C++ to stop classes from inheriting
from a class is:
I don't think it's a common pattern. At least, I've never
seen it. There are many reasons for inheriting from a
class, not just the typical OO ones. And blocking them
generally isn't a good idea.
I only toyed with the idea of blocking once: whenever the
standard marks a type as implementation defined (e.g.,
vector::iterator) but does not guarantee that you can derive
from it (note that vector::iterator could be a pointer) then
my library should at least offer a version that flags attempts
do derive as errors. To that end, I would make
vector::iterator final.
That's an interesting idea---if the contract doesn't guarantee
derivability, forbid it. On the other hand, it clashes with
code which wants to do something different with class types,
e.g. use a memcpy on non-class types.
(The most obvious reason is in template
metaprogramming: if you can inherit from it, it is a class
type.)
I picked up the following test:
template < typename T >
class is_class_type {
template < typename S >
static yes_type check ( int S::* );
template < typename S >
static no_type check ( ... );
public:
static bool const value =
( sizeof( check<T>( 0 ) ) == sizeof(yes_type) );
}; // is_class_type
As far as I can see, it does not use derivation. What did you
have in mind?
I don't really know, to tell the truth. I'm not at all an
expert on template meta-programming---it's far too complicated
for me---, but when the question of adding final classes to C++
was raised, the experts in meta-programming (David Abrahams, for
example) strongly opposed the idea because it would break some
meta-programming idioms. My suggestion in parentheses was just
a quick guess as to why it might be used. (Although come to
think of it... what little meta-programming I've done has used
something along the lines of what you posted.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34