On Wed, Feb 17, 2010 at 12:19 AM, Romain Francois <
romain.francois.r.enthusi...@gmail.com> wrote:
> On 02/17/2010 12:51 AM, Kenton Varda wrote:
>
>> The Reflection interface already provides a way -- FieldSize() and
>> GetRepeatedX(). The only problem is that it's a bit slower than the
>> genera
On 02/17/2010 12:51 AM, Kenton Varda wrote:
On Tue, Feb 16, 2010 at 2:47 PM, Romain Francois
mailto:romain.francois.r.enthusi...@gmail.com>> wrote:
Thanks for the feedback.
On 02/16/2010 10:44 PM, Kenton Varda wrote:
GeneratedMessageReflection is an internal class used by the
On Tue, Feb 16, 2010 at 2:47 PM, Romain Francois <
romain.francois.r.enthusi...@gmail.com> wrote:
> Thanks for the feedback.
>
>
> On 02/16/2010 10:44 PM, Kenton Varda wrote:
>
>> GeneratedMessageReflection is an internal class used by the protobuf
>> implementation. Currently, users are not allo
Thanks for the feedback.
On 02/16/2010 10:44 PM, Kenton Varda wrote:
GeneratedMessageReflection is an internal class used by the protobuf
implementation. Currently, users are not allowed to use it directly,
because we may change it at any time. You're suggesting that we promote
it to a public
GeneratedMessageReflection is an internal class used by the protobuf
implementation. Currently, users are not allowed to use it directly,
because we may change it at any time. You're suggesting that we promote it
to a public interface, which has implications with regard to maintenance
costs and i
Hello,
Thanks for the answers.
Maybe I should give some more background on why this is of interest to
me. In RProtoBuf, we essentially only use the reflection api so that we
can dynamically load new proto message types at runtime, etc ... we
don't use protoc and therefore have no access to th
Yeah, it would add a lot of complication and reduce the flexibility of the
Reflection interface. We don't want to require repeated fields to be
implemented in terms of RepeatedField or RepeatedPtrField.
On Fri, Feb 12, 2010 at 12:11 PM, Jason Hsueh wrote:
> +kenton
>
> Kenton may have a better
+kenton
Kenton may have a better answer, but I surmise that it's to avoid tying the
Reflection interface to implementation details. A Message implementation
might not use RepeatedField at all. The original version of protobufs used a
different class to represent repeated fields, so it wouldn't hav
Why not ? It seems reasonnable to want to use e.g. std::copy and friends.
On the documentation it says :
"
Most users will not ever use a RepeatedField directly; they will use the
get-by-index, set-by-index, and add accessors that are generated for all
repeated fields
"
What if I do want to
No, there isn't a way to get the RepeatedField from the reflection
interface. You can only do so via the generated interface.
On Thu, Feb 11, 2010 at 5:57 AM, Romain Francois <
romain.francois.r.enthusi...@gmail.com> wrote:
> Hello,
>
> How can I get hold of a RepeatedField object to manage a rep
Hello,
How can I get hold of a RepeatedField object to manage a repeated field
in C++.
In RProtoBuf, we do a lot of :
for( int i=0; iGetRepeatedInt32( *message, fieldDesc, i ) ;
}
where essentially the INTEGER macro gives a pointer to the beginning of
the int array w
11 matches
Mail list logo