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
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 for.shin1...@gmail.com wrote:
I'm
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 liuj...@google.com wrote:
We discussed internally and decided not to
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
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 jaybo...@gmail.com wrote:
I'd also note that this precludes
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 tequila...@ymail.com wrote:
the corner-stone of Hash* containers is:
(A.equals(B)) = (A.hashCode() == B.hashCode()) for all A, B.
From what Ive gathered, this invariant is true for protocol buffer's
implementation of equals() and hashCode(). The
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
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
On Wed, May 18, 2011 at 12:44 PM, Jay Booth jaybo...@gmail.com 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
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
13 matches
Mail list logo
