[C++-sig] TypeError: No to_python (by-value) converter found for C++ type: class std::basic_ostream<char, struct std::char_traits<char> >

[Jakub Zytka]

On 09/29/10 14:11, Simon W wrote:
> Thank you for the answer. Is there any way I can prevent it from copying the
> stream object even though std::ostream::write() returns a std::ostream& ?
You can use other return policy, or define one on your own.

http://www.boost.org/doc/libs/1_44_0/libs/python/doc/tutorial/doc/html/python/functions.html#python.call_policies

But honestly, I do not think it is the correct way to go. Read below.

 > I'm trying to serialise some data. I have a c++ class:
 >          class ostream
 >          {
 > ...
 > could to the c++ way and add a integer before the byte stream that reveal how
 > big it is. But How can i serialise an int from python that takes up constant
 > "byte-size" for an integer between lets say 0-10000!?
Everything can be done, but I have a different question:
I haven't followed all your previous emails, but do you *really* need to 
implement serialization code in python?
Somehow I feel it is very weird that on one hand you want to have serialization 
code in python, and yet use ostream.

What would be wrong with coding serialization purely in C++, and then providing 
appropriate pickle suite to python:
struct MyPickleSuite
{
// ...
boost::python::tuple MyPickleSuite::getstate(MyClass & object)
{
std::ostringstream oStream(ios_base::binary);
serialize(oStream, object);
return boost::python::make_tuple(oStream.str());
}

void MyPickleSuite::setstate(MyClass & object, boost::python::tuple state)
{
// verify tuple correctness etc.
std::string serializedData = extract<std::string>(state[0]);
std::istringstream iStream(serializedData, ios_base::binary);
serialize(iStream, object); // NOTE: you can use the same code for serialization 
and deserialization. stream type should determine actual behavior
}
}

That way you do not have to expose ostream to python at all. In fact if you 
wanted to switch to another type of stream (imagine that you have a custom 
stream implementation, which provides eg. type checking) it is cheap. You only 
change a few functions in your pickle suite, nothing more.

Even if you do really need to define serialization in python I see no reason to 
play with streams. I'd rather had a wrapper which hides underlying 
implementation (eg. std::streams) and operates on strings.

Please reconsider your design.