[protobuf] gcc optimization flags

2011-05-18 Thread akk142
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

[protobuf] undefined reference to GzipInputStream

2011-05-18 Thread Shin
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

Re: [protobuf] undefined reference to GzipInputStream

2011-05-18 Thread Kenton Varda
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

[protobuf] Re: Generated hashcode() returns different values across JVM instances?

2011-05-18 Thread Jay Booth
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() >

[protobuf] Re: Generated hashcode() returns different values across JVM instances?

2011-05-18 Thread Jay Booth
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

Re: [protobuf] Re: Generated hashcode() returns different values across JVM instances?

2011-05-18 Thread Jason Hsueh
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

Re: [protobuf] Re: Generated hashcode() returns different values across JVM instances?

2011-05-18 Thread Jason Hsueh
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

[protobuf] RPC layer over protocol buffers

2011-05-18 Thread Anurag
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

Re: [protobuf] Re: Generated hashcode() returns different values across JVM instances?

2011-05-18 Thread Ron Reynolds
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

Re: [protobuf] Re: Generated hashcode() returns different values across JVM instances?

2011-05-18 Thread Jason Hsueh
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

[protobuf] Re: Generated hashcode() returns different values across JVM instances?

2011-05-18 Thread Jay Booth
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

Re: [protobuf] Re: Generated hashcode() returns different values across JVM instances?

2011-05-18 Thread Jason Hsueh
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

Re: [protobuf] Re: Generated hashcode() returns different values across JVM instances?

2011-05-18 Thread Jay Booth
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

Re: [protobuf] Re: Generated hashcode() returns different values across JVM instances?

2011-05-18 Thread Jason Hsueh
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

[protobuf] Proto file generation from Descriptors in Java (DebugString)

2011-05-18 Thread Ben Wright
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