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.)
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
$team->member($i)->set_first_name('Dave');
won't have the same effect as (C++)
team.mutable_member(i)->set_first_name("Dave");
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.
-dave
--~--~---------~--~----~------------~-------~--~----~
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
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---
