On Fri, 2008-10-03 at 02:29 +0530, Danushka Menikkumbura wrote:
> > Hmmmm, that's too bad. I'd like to avoid creating a buffer and then
> > copying it over ("minimize the movement of data"). Is there a better
> > way to write binary data directly into the message contents without
> > creating a buffer first?
> Jonathan,
>
> When I go through the code (framing::TransferContent) I can clearly see
> that the current implementation can not handle binary data.
>
> At the moment "data" is a std::string and the method "setData" assigns
> the incoming string value to this std::string variable directly. When it
> comes to binary data, we can see null terminators in the middle and
> hence assigning the binary data stream to a std::string will definitely
> truncate the data. So what we will have in the message is just a part of
> the original binary data.
It will NOT truncate the data if you use the correct assignment
functions. std::string is perfectly capable of holding strings
containing null obviously any of the c-string funtions taking a char*
will not work but those taking a char* and a length will work fine.
E.g.
std::string bad("abc\0def"); // Will contain just "abc"
std::string good("abc\0def", 7); // Will contain "abc\0def"
> So, as a solution for this, we need to have two class level variables to
> keep binary data.
>
> 1. void* data;
> 2. long dataLength;
That is exactly what std::string contains (plus a reference count
typically for copy-on-write)
> These two are enough to say all about our binary data dump. So,
> obviously we need to have separate methods to get and set binary data.
>
> We may make use of these changes to keep string data as well so that we
> can drop the current std::string variable.
>
> I can send you a patch if we are happy with this.
A simple pointer+length is not sufficient here - the thing that's
missing is memory management policy. I agree that std::string's policy
is not ideal since it may impose an extra copy of data in some cases,
but if add other options they need to have well defined, automatable
memory management policies. If messages are sent asynchronously the
application has no way of knowing exactly when Qpid is finished with the
data, e.g. via an (optional) user supplied deletion callback (similar to
boost::shared_ptr)
