Hi,
What gcc optimization flags do you recommend to get the best
performance? Is O2 or O3 best? Do you recommend anything not
included in O2 or O3?
Thanks,
-Andy
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send
I'm learning how to use the gzip stream.
The error msg always bother me.
It saying:
undefined reference to
`google::protobuf::io::GzipInputStream::GzipInputStream(google::protobuf::io::ZeroCopyInputStream*,
google::protobuf::io::GzipInputStream::Format, int)
It seems only found the header file b
GzipInputStream is only compiled into the library if zlib is available,
since it depends on zlib. On Unix you should be able to fix this by
installing libz.so, on MSVC you may need to modify the project files a bit.
On Wed, May 18, 2011 at 12:18 AM, Shin wrote:
> I'm learning how to use the gzi
Well, that's your prerogative, I guess, but why even implement
hashcode at all then? Just inherit from object and you're getting
effectively the same behavior. Is that what you're intending?
On May 16, 10:03 am, Pherl Liu wrote:
> We discussed internally and decided not to make the hashCode()
>
I'd also note that this precludes usage of protobuf objects in
HashSets or as keys in HashMaps -- any time someone does that, it will
be a (subtle and confusing) bug, as hashcode() isn't aligned with
equals().
On May 18, 2:48 pm, Jay Booth wrote:
> Well, that's your prerogative, I guess, but why
Jumping in late to the thread, and I'm not really a Java person, so I may be
misunderstanding something here. But as far as I can tell, you are asking
for hashCode() to be a 'consistent' hash across processes. hashCode() as
implemented is still useful within a single JVM, allowing you to use
protob
Ah, I didn't get this message. How does this break use in a HashMap? Given
two protobufs of the same type in the same JVM, with the same contents, does
hashCode() not return the same value?
On Wed, May 18, 2011 at 11:50 AM, Jay Booth wrote:
> I'd also note that this precludes usage of protobuf o
Hi All,
Does anyone knows any good implementation of rpc in c++
which i can use with protocol buffers
to take care of networking.
Thanks
Anurag
--
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to pr
the corner-stone of Hash* containers is:
(A.equals(B)) => (A.hashCode() == B.hashCode()) for all A, B.
tho it's not explicitly stated it would seem to be implied that is within a
single JVM.
not sure if the code in question maintains that rule within a JVM (if not
that's
a big deal).
if so
On Wed, May 18, 2011 at 12:08 PM, Ron Reynolds wrote:
> the corner-stone of Hash* containers is:
> (A.equals(B)) => (A.hashCode() == B.hashCode()) for all A, B.
>
>From what I"ve gathered, this invariant is true for protocol buffer's
implementation of equals() and hashCode(). The descriptor obj
Right, I forgot that the Descriptor object is statically initialized
so it'll be consistent within the JVM.
I still think that in the context of serializable objects, (i.e.
objects intended to be transported between JVMs in some way, shape or
form) a consistent hashCode would be useful for a lot o
Well, hashing the serialization as Pherl/Kenton suggested gives you that,
and seems cleaner and more direct than making hashCode() of the in-memory
object assume that you are doing something across JVMs.
(Also, unknown fields are pretty common when you may have a jungle of
binaries, which is true
That definitely seems acceptable. Any reason not to make the default
implementation return toByteString().hashCode() and get the best of
both worlds? It's a little more expensive probably, but
Object.hashCode() is already deceptively expensive to begin with.
I personally switched my particular p
On Wed, May 18, 2011 at 12:44 PM, Jay Booth wrote:
> That definitely seems acceptable. Any reason not to make the default
> implementation return toByteString().hashCode() and get the best of
> both worlds? It's a little more expensive probably, but
> Object.hashCode() is already deceptively ex
There has been some back and forth previously about java language
support for generating a proto file from a Descriptor.
The suggested implementation was to either wrap or port the
DebugString capability from decriptor.cc
I recently ported the DebugString capability to java - it's a bit
rough as
15 matches
Mail list logo