Hugo van der Merwe <hugo@[...].za>  writes:

>  I had a look at the mailing list archives about this topic, I'm still
>  not clear on how exactly it works:
> 
> > #include <boost/python/module.hpp>
> > #include <boost/python/class.hpp>
> >
> > struct Num {
> >    Num() {}
> >    ~Num() {}
> >    static int getDims() {return 3;}
> >    int dims() {return 5;}
> > };
> >
> > BOOST_PYTHON_MODULE_INIT(numTest)
> > {
> >    using namespace boost::python;
> >    module numTestMod("numTest");
> >    numTestMod
> >       .add
> >       ( class_<Num>("Num")
> >         .def_init()
> >         .def("getDims",&Num::getDims)
> >         .def("dims", &Num::dims)
> >         )
> >       ;
> > }
> 
> > We don't have a way to make true static methods yet.

This part is still true.

> > getDims will work fine if you access it through the class like this:
> > 
> >     Nums.getDims()

I was wrong when I posted that.

>  I am trying to wrap a "Settings" class which does not have a public
>  constructor, it expects you to call "GetInstance" to get a pointer to
>  the always-existing instance (making the settings "global"). The above
>  would make me think that this will work:
> 
>  	class_<Settings, boost::noncopyable>("Settings", no_init)
>  	.def("GetInstance", &Settings::GetInstance,
>  	     return_value_policy<reference_existing_object>());
> 
>  I cannot call Settings.GetInstance(), it gives me:
> 
>  TypeError: unbound method Boost.Python.function object must be called with Settings instan
ce as first argument (got nothing instead)


Right, that won't work.

>  I also read about an approach that looks something like this:
> 
>      object settings_class =
>  	class_<Settings, boost::noncopyable>("Settings", no_init);
>      settings_class.attr("Settings") = &Settings::GetInstance;
> 
>  But I don't know how that is supposed to work...

Yeah, that won't work either.

>  If I wanted to expose GetInstance as Settings() instead (once I get it
>  working), is it as simple as just calling it "__init__" instead?

Unfortunately, no. That would be cool, though, wouldn't it?  I'm
pretty sure you can do this after you define class_<Settings> , though:

    // Note no leading dot.
    def("Settings", &Settings::GetInstance
        , return_value_policy<reference_existing_object> ());

This will replace the class in the module by a function called
Settings that gets the instance.

>  (Should I then have no_init in the class_<> invocation or not? 

Yep.

>  I noticed the tutorial talks about no_init, but then mentions as
>  soon as you wish to derive classes from it, you do not want
>  no_init. So when is no_init useful? Only when you cannot construct a
>  class and don't want to derive from it, i.e. when you're using
>  "factories"?)

I think that's right. However, I wonder if we should change the
__init__ function that you get from no_init to be a no-op unless the
Python class actually has the same type as the abstract base...

>  I am really astonished with what can be achieved with C++ -
>  Boost.Python is really amazing!

Thank you!

-- 
                       David Abrahams
   dave@[...].com * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution


_______________________________________________
C++-sig mailing list
C++-sig@[...].org
http://mail.python.org/mailman/listinfo/c++-sig