boost.python字符串管理

Question

How does boost.python handle std::string member variables? Specifically, if I have a class and its boost.python wrapper

class A {
public: 
    std::string name;
};
class_<A>("AWrapper")
.def_readwrite("name", &A::name);

how is the correspondence between std::string object and PyObject it(string) representing is handled: is boost::python::object(ie PyObject) created which stores pointer to the string, thus this object servers as a proxy? Thus, each time I want to retrieve string member's value, PyString object is created? Can interning mechanism be applied to such string objects?

Answer 1

Short answer: your suspicions and insight about the behaviour is mostly correct, boost-python will interpret your configuration to produce a simple and inefficient behaviour, however it provides support mechanisms to override and extend this. This may be a lot of work.

Long answer:

is boost::python::object(ie PyObject) created which stores pointer to the string, thus this object servers as a proxy?

No.

Python-strings are immutable and by default (with your configuration) boost-python will convert the std::string into a new python string (str). So there is no proxying going on.

Thus, each time I want to retrieve string member's value, PyString object is created?

Yes. The following assertion will fail, where I attempt to verify that the python references to the strings have the same python object id.

input = 'some value'
sut = AWrapper()
sut.name = input
assert id(sut.name) == id(input)

Can interning mechanism be applied to such string objects?

For example, if you can enable caching of the created python string-object for a given c++ string, to then return a previously created python string-object when available? The answer is also yes, it is possible. The boost-python concepts are call policies or custom converters . (Both are not part of the tutorial for boost-python.)

You would either extend every def_readwrite call with an appropriate call policy, or overwrite the general built-in converter for std::string to/from PyString , to introduce this theoretical cache.

Keep in mind, python strings are immutable and std::string is mutable. So you will have issues when the member is changed from the C++ side. Additionally, such hooks will also cost performance at runtime when the code handles every single get and set operation.