Re: [pygccxml-development] Abstract Classes

[Lakin W. <lak...@gm...>]

My bad.  It _does_ seem to work out of the box.  The problem was that
I had excluded a parent class which had pure virtual functions,
because it had some void* stuff that I was going to deal with later
...

Sorry for the confusion and noise.


lakin

On 5/31/06, Lakin Wecker <lak...@gm...> wrote:
> Maybe I was not clear.  I'm talking about pure virtual functions.  You
> had mentioned at some point that I may have to take care of these in a
> certain way.
>
> For instance:
>
> g++ `pkg-config --cflags OGRE` -I/usr/include/python2.4
> -DBOOST_PYTHON_MAX_ARITY=16 -O0 -g -I./ -fPIC -Ibuild -c -o
> build/RenderWindow.pypp.os build/RenderWindow.pypp.cpp
> /usr/include/boost/python/object/value_holder.hpp: In instantiation of
> 'boost::python::objects::value_holder<RenderWindow_wrapper>':
> /usr/include/boost/type_traits/alignment_of.hpp:52:   instantiated
> from 'const size_t
> boost::detail::alignment_of_impl<boost::python::objects::value_holder<RenderWindow_wrapper>
> >::value'
> /usr/include/boost/type_traits/alignment_of.hpp:61:   instantiated
> from 'boost::alignment_of<boost::python::objects::value_holder<RenderWindow_wrapper>
> >'
> /usr/include/boost/python/object/instance.hpp:30:   instantiated from
> 'boost::python::objects::instance<boost::python::objects::value_holder<RenderWindow_wrapper>
> >'
> /usr/include/boost/python/object/instance.hpp:44:   instantiated from
> 'const size_t boost::python::objects::additional_instance_size<boost::python::objects::value_holder<RenderWindow_wrapper>
> >::value'
> /usr/include/boost/python/class.hpp:499:   instantiated from 'void
> boost::python::class_<T, X1, X2, X3>::initialize(const DefVisitor&)
> [with DefVisitor = boost::python::init<mpl_::void_, mpl_::void_,
> mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_,
> mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_,
> mpl_::void_, mpl_::void_, mpl_::void_, mpl_::void_>, W =
> RenderWindow_wrapper, X1 = boost::noncopyable_::noncopyable, X2 =
> boost::python::detail::not_specified, X3 =
> boost::python::detail::not_specified]'
> /usr/include/boost/python/class.hpp:629:   instantiated from
> 'boost::python::class_<T, X1, X2, X3>::class_(const char*, const
> char*) [with W = RenderWindow_wrapper, X1 =
> boost::noncopyable_::noncopyable, X2 =
> boost::python::detail::not_specified, X3 =
> boost::python::detail::not_specified]'
> build/RenderWindow.pypp.cpp:158:   instantiated from here
> /usr/include/boost/python/object/value_holder.hpp:66: error: cannot
> declare field 'boost::python::objects::value_holder<RenderWindow_wrapper>::m_held'
> to be of abstract type 'RenderWindow_wrapper'
> build/RenderWindow.pypp.cpp:18: note:   because the following virtual
> functions are pure within 'RenderWindow_wrapper':
> /home/lakin/.local/include/OGRE/OgreRenderTarget.h:267: note:  virtual
> void Ogre::RenderTarget::writeContentsToFile(const Ogre::String&)
> /home/lakin/.local/include/OGRE/OgreRenderTarget.h:273: note:  virtual
> bool Ogre::RenderTarget::requiresTextureFlipping() cons
>
>
> Lakin
>
> On 5/30/06, Roman Yakovenko <rom...@gm...> wrote:
> > On 5/31/06, Lakin Wecker <lak...@gm...> wrote:
> > > In Ogre, a frequent design used is to define an abstract base class,
> > > (Say RenderWindow).  Along with a Manager/Factory that creates that
> > > window for you.  Then the platform specific implementations of those
> > > classes are built to actually do the work.
> > >
> > > However, the API dictates that you ask the Manager/Factory for an
> > > implementation of RenderWindow (you don't care which), and you then
> > > use it as a generic RenderWindow interface.
> > >
> > >
> > > In py++, how do I model this?  I don't want to expose the platform
> > > specific implementations of the classes, as they're not needed. But I
> > > do need to somehow let the python run time know about the
> > > AbstractClass so that when I ask the Manager for one, I can use it
> > > from Python.
> > >
> > > When I directly include the class in the ouput, I get a compile error
> > > because of the lack of implementations ... of some methods.
> >
> > I could be wrong, but it should work out of the box. I will check this at home.
> >
> > > Anyways, I'm going to sleep now.  See you all in a few hours.
> >
> > Good night
> >
> > > Lakin
> >
> >
> > --
> > Roman Yakovenko
> > C++ Python language binding
> > http://www.language-binding.net/
> >
>