[C++-sig] tutorial class_data_members compile problem

[David Abrahams]

"Joel de Guzman" <djowel at gmx.co.uk> writes:

> ----- Original Message ----- 
> From: "David Abrahams" <dave at boost-consulting.com>
> 
> > * continuing the example and trying to make an instance of the Python
> >   class Derived, I also get a:
> > 
> >   RuntimeError: This class cannot be instantiated from Python
> 
> Right. It needs an __init__() function to suppress the Base class'
> __init__. 
> 
> 
> Hmm, I wonder if we should change that? It could check the object's
> __class__ before raising that exception. That wouldn't prevent people
> from instantiating subclasses that don't implement the pure virtual
> functions, but that would be caught later by an AttributeError when
> they try to call the function. Opinions?
> 
> -----------------------------
>
> I think it's ok as it is. It will do more but the end result is the
> same right?

If we change it, users who subclass abstract base classes will not
have to implement an __init__ function just to shut the base class up.
However, as I think more about it, I think a more-drastic fix may be
needed. After all, it is the C++ init function which creates the C++
class instance, which is needed for obvious reasons. If you subclass
an abstract class Base in Python, it has to create an instance of the
class wrapper BaseWrap...

...so carrying this line of thinking a little further, the user has to
expose some accessible __init__ function for derived classes to
call. That will cover up the one which raises the Python exception
anyway, (I hope - but I think not, now... anyway, users don't have to
use no_init here) so I guess it's OK. It might be nice to have the
__init__ functions exposed by the user raise the Python exception if
the Python type is Base, but that doesn't look too achievable anyway
;-).

I hope you followed my twisty thinking above. If not, sorry.

> I'll wait for your conclusion and correct the tutorial appropriately.

Whatever you write is fine, as long as it's backed up by experimental
data ;-)

-- 
           David Abrahams * Boost Consulting
dave at boost-consulting.com * http://www.boost-consulting.com