[C++-sig] Wrapping internal references to std::string

Bruce Lowery bruce_lowery at yahoo.com
Wed Jan 15 15:33:55 CET 2003


David, I only just saw your response to my question (below) on the Users' list
where I had posted this question before I realized that boost.pythons questions
were preferred on this list.  Sorry for the noise.

--bruce


--- Bruce Lowery <bruce_lowery at yahoo.com> wrote:
> 
> --- David Abrahams <dave at boost-consulting.com> wrote:
> > Bruce Lowery <bruce_lowery at yahoo.com> writes:
> > 
> > > On the Boost Users' list, it was explained to me that for a case like the
> > > following:
> > >
> > > class Bar {
> > > public:
> > >    const std::string& get() { return _s; }
> > > private:
> > >    std::string _s;
> > > };
> > >
> > > BOOST_PYTHON_MODULE( Foo )
> > > {
> > >    class_<Bar>("Bar")
> > >       .def( "get", &Bar::get, return_internal_reference<>() )
> > >       ;
> > > }
> > >
> > > the return_internal_reference<>() would try to wrap a pointer to the
> > returned
> > > var (_s above) in a Python object, and so something like a
> > class_<std::string>
> > > would have to be defined to avoid raising an exception.  It was also
> > explained
> > > that the result wouldn't really act like a python string without
> additional
> > > work.
> > >
> > > What I think I'd like to do is introduce an extra class, say FooString,
> > that
> > > would encapsulate the std::string pointer and have methods matching those
> > of
> > > the python string class except that they'd be implemented in terms of
> > > std::string methods and act on the underlying std::string object.
> > >
> > > I've been looking at the Python and Boost.Python documentation related to
> > > introducing new types (e.g the 'noddy' example).  
> > 
> > Why not just use class_<std::string> for this?
> > 
> > > The aim would be, from python, to have Foo.Bar.get return a python object
> > that
> > > acted like a python string even though it wasn't.
> > >
> > > Does this seem reasonable?  I'm only a few days old in the worlds of both
> > > Python and Boost.Python, so your advice is well received.
> > >
> > > Is there an easier way to do this?  
> > 
> > It would be trivial (though tedious) to do it with
> > class_<std::string>.  Why don't you just do that?
> 
> 
> I believe you had indicated this in a response to an earlier posting.
> 
> Since the std::string methods and python string methods do not line up well,
> I
> can't map like this:
> 
> class_<std::string>("string")
>    .def( "find", &std::string::find )
>    .def( "capitalize", &std::string::?? )
>    etc
> 
> which is the only way I know how to map at this point (also learned  how to
> handle overloading from someone else's posting).
> 
> Obviously you are more familiar with this than I am.  Can you show an example
> that I could use to figure out the other mappings?  For instance, how would
> the
> python string 'find' method be mapped using '.def'?  I would much prefer to
> do
> it this way rather than the other way (introducing a new type) if possible.
> 
> --bruce
> 
> 
> > 
> > > BTW, it's forbidden for me to change the actual API that I'm
> > > wrapping, in order to avoid problems like this, so I really need a
> > > solution.
> > 
> > Understood.
> > 
> > -- 
> >                        David Abrahams
> >    dave at boost-consulting.com * http://www.boost-consulting.com
> > Boost support, enhancements, training, and commercial distribution
> > 
> > 
> > _______________________________________________
> > C++-sig mailing list
> > C++-sig at python.org
> > http://mail.python.org/mailman/listinfo/c++-sig
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> _______________________________________________
> C++-sig mailing list
> C++-sig at python.org
> http://mail.python.org/mailman/listinfo/c++-sig


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com




More information about the Cplusplus-sig mailing list