On Dec 3, 2:00 pm, Dave Bailey <[EMAIL PROTECTED]> wrote:
> On Dec 2, 10:49 pm, Kenton Varda <[EMAIL PROTECTED]> wrote:
> > C++ compatibility matters because eventually we want to be able to generate
> > Python code which just wraps C++ code for efficiency.  C++ isn't garbage
> > collected, so append() can't easily be implemented in this case without
> > having ownership problems.  Slice assignment has the same problem.
> > Also note that even pure-python protocol buffers have a sort of "ownership"
> > issue:  Sub-messages all contain pointers back to their parents, so that
> > when a sub-message is modified, the parent's cached size can be marked
> > dirty.  (Also, singular sub-messages have to inform their parents when the
> > first field within them is set, but that doesn't apply here.)

(Here is my post without all of the ridiculous formatting):

While you're on this topic, I ran into this ownership issue while
implementing the Perl/XS wrapper around the generated C++ code.  I
think it is the same issue that would face the author of a Python or
Ruby C++ extension of the generated C++.  I ended up having to new() a
copy of every message that I transferred from C++ to Perl or vice
versa.  So, for example, a statement like


won't have the same effect as (C++)


because $team->member($i) will generate a copy of the underlying C++
object, so that it can be managed by Perl's reference counting without
any concern as to whether or not the underlying C++ object has been
deleted because the containing message went out of scope.

Anyway, I thought it might be possible to allow for shared ownership
of a message object if there were a reference counted variant of
RepeatedPtrField<T> (something like RepeatedSharedPtrField<T> or
whatever), which would provide incref() and decref() methods such that
Perl and C++ could use the same underlying C++ objects in the
generated code.  This would really help the performance of the Perl/XS
code if all of that copy construction could be avoided somehow.  The C+
+ code generator would need an option that would instruct it to
generate RepeatedSharedPtrField<T> members (and incref and decref
calls, where appropriate) for repeated messages (instead of using the
default RepeatedPtrField<T>).

What do you think?  Is something like this possible, even though it
would require a change to protobuf?  It is an issue for all {Python,
Perl, Ruby, ...}/C++ extension wrappers for Protocol Buffers.  I have
found that protobuf is a faster Perl data serialization mechanism that
the (generic) Storable module, but I think it can be even faster.


You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 

Reply via email to