The code generated by protoc seems to go to great lengths to make sure
that once a message object is created, it can't be modified. I'm
guessing that this is to avoid cycles in the object graph, so that the
serialization routine doesn't have to detect cycles. Is this
correct? Would a cycle in t
Hi,
I am trying to build protobuf 2.0.3 on FreeBSD 7.1 and am running into
an error in the make immediately after the link step.
I run configure with the --disable-shared argument, then run make.
The make appears to compile all of the code, and successfully produces
the archives in the src/.libs
just create a free account and you got $27 us dollar and referral
your friends one referral you will earn $1.25 us dollar so more
referral earn more its all free just create a free account.thereafter
you will get.$2000 to $5000 p.m
http://www.AWSurveys.com/HomeMain.cfm?RefID=b
On Apr 23, 1:03 pm, Kannan Goundan wrote:
> The code generated by protoc seems to go to great lengths to make sure
> that once a message object is created, it can't be modified. I'm
> guessing that this is to avoid cycles in the object graph, so that the
> serialization routine doesn't have to d
In many ways this is an implementation detail, though. protobuf-net
takes the other (mutable classes) approach - and indeed one
consequence is that it needs to be careful about loops when
serializing. That needn't be too invasive, though: I simply track the
depth, and don't even bother tracking ob
It appears as if your make is not properly expanding the $^ variable -- it's
replacing it with the empty string. Try using gmake?
On Thu, Apr 23, 2009 at 8:22 AM, wrote:
>
> Hi,
>
> I am trying to build protobuf 2.0.3 on FreeBSD 7.1 and am running into
> an error in the make immediately after t
You're specifically talking about the Java implementation. We quite
intentionally chose to make message objects completely immutable. Version 1
of protocol buffers (never released publicly) used mutable objects, and we
found it lead to many bugs as people would modify messages that were
simultane
The reason I'm asking all this is that I'm implementing a data
serialization format that has the same usage model as protocol buffers
(i.e. generate language bindings, serialize/deserialize).
For me, the biggest benefit of immutability here is that it prevents
cycles in the object graph. (Well,
On Thu, Apr 23, 2009 at 3:59 PM, Kannan Goundan wrote:
> The reason I'm asking all this is that I'm implementing a data
> serialization format that has the same usage model as protocol buffers
> (i.e. generate language bindings, serialize/deserialize).
>
> For me, the biggest benefit of immutabil