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.
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
