And I forgot to tell you, the python class in an extension of a c++
class. Hence I have the serialise and deserialise function defined in
python.
// Simon
On 29 sep 2010, at 16.02, Jakub Zytka <ku...@kormoran.net> wrote:
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
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
