Thread: [pygccxml-development] Abstract Classes
Brought to you by:
mbaas,
roman_yakovenko
From: Lakin W. <lak...@gm...> - 2006-05-31 04:47:07
|
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. Anyways, I'm going to sleep now. See you all in a few hours. Lakin |
From: Roman Y. <rom...@gm...> - 2006-05-31 04:50:58
|
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/ |
From: Lakin W. <lak...@gm...> - 2006-05-31 12:39:46
|
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/ > |
From: Lakin W. <lak...@gm...> - 2006-05-31 15:10:07
|
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/ > > > |
From: Roman Y. <rom...@gm...> - 2006-05-31 17:53:29
|
On 5/31/06, Lakin Wecker <lak...@gm...> wrote: > 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. You are not completly wrong. In most cases, py++ guide-line - "user knows better". But there are cases, when py++ say - "no way, he made a mistake". Your use case is a second one. In this case py++ should at least generate some warning in source file. Can you post small example of code? I will add it to my todo list. Thanks -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/ |