[protobuf] Re: gcc4.4 fixes: std::tr1::unordered_map

2009-12-21 Thread Kenton Varda
Thanks for the fix! Unfortunately your re-ordering makes it hard for me to see what actually changed. Also, your style doesn't match the Google style guide. Is the following sufficient for hash.h, given your changes to stl_hash.m4? Index: src/google/protobuf/stubs/hash.h ===

[protobuf] Re: gcc4.4 fixes: std::tr1::unordered_map

2009-12-21 Thread Kenton Varda
Apparently not, as tr1::hash treats values as pointers, not strings. :/ On Mon, Dec 21, 2009 at 10:26 AM, Kenton Varda wrote: > Thanks for the fix! Unfortunately your re-ordering makes it hard for me to > see what actually changed. Also, your style doesn't match the Google style > guide. > >

[protobuf] Re: gcc4.4 fixes: std::tr1::unordered_map

2009-12-21 Thread Oleg Smolsky
Hey Kenton, you also need the two updated google::protobuf::hash<> specializations that ensure correct hashing of "const char *" and "std::string" keys. I've attached the complete header, so that you can read it without having to apply the patch. Oleg. On Mon, Dec 21, 2009 at 10:26 AM, Kenton Va

[protobuf] Re: gcc4.4 fixes: std::tr1::unordered_map

2009-12-21 Thread Kenton Varda
Yes, I see now. But your solution -- constructing string objects every time the hash function is run -- is very slow. I've submitted r259 with this implementation instead: template <> struct hash { inline size_t operator()(const char* str) const { size_t result = 0; for (; *str != '\0'

[protobuf] Re: gcc4.4 fixes: std::tr1::unordered_map

2009-12-21 Thread Oleg Smolsky
Alright, thanks. Oleg. On Dec 21, 10:59 am, Kenton Varda wrote: > Yes, I see now.  But your solution -- constructing string objects every time > the hash function is run -- is very slow.  I've submitted r259 with this > implementation instead: > > template <> > struct hash { >   inline size_t op

[protobuf] Re: gcc4.4 fixes: std::tr1::unordered_map

2009-12-21 Thread Oleg Smolsky
BTW, you've added this line to stubs/hash.h #include but it should not be there. Includes are already handled by these: #include HASH_MAP_H #include HASH_SET_H Oleg. -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group,

[protobuf] Re: gcc4.4 fixes: std::tr1::unordered_map

2009-12-21 Thread Kenton Varda
Arrghh. I didn't mean to add that... I just wrote it so that I could hit F3 and have eclipse show me the file, then forgot to delete it. Fixed. Thanks for pointing that out; I'm not normally so sloppy. On Mon, Dec 21, 2009 at 11:19 AM, Oleg Smolsky wrote: > BTW, you've added this line to stub

[protobuf] Re: gcc4.4 fixes: std::tr1::unordered_map

2010-01-06 Thread Kenton Varda
The implementation of tr1::hashtable on OSX 1.5 (GCC 4.0.1) is broken. find_node() is apparently not declared const, meaning calling find() on a const hash_map does not compile. /cry On Mon, Dec 21, 2009 at 11:24 AM, Kenton Varda wrote: > Arrghh. I didn't mean to add that... I just wrote it

[protobuf] Re: gcc4.4 fixes: std::tr1::unordered_map

2010-01-06 Thread Kenton Varda
Worked around with r291. Must test on all platforms all over again... sigh. On Wed, Jan 6, 2010 at 8:29 PM, Kenton Varda wrote: > The implementation of tr1::hashtable on OSX 1.5 (GCC 4.0.1) is broken. > find_node() is apparently not declared const, meaning calling find() on a > const hash_map

[protobuf] Re: gcc4.4 fixes: std::tr1::unordered_map

2010-01-06 Thread Oleg Smolsky
Oh, funky. Sorry, I don't have a Mac to test. Do you have automated builds going? >From my experience gcc 4.0.x versions were somewhat buggy, while the 4.1.x branch is reasonable. I am surprised that std::tr1 was actually present in that STL... Perhaps it is an Apple-brewed combo? Oleg. On Wed,

[protobuf] Re: gcc4.4 fixes: std::tr1::unordered_map

2010-01-06 Thread Kenton Varda
On Wed, Jan 6, 2010 at 9:02 PM, Oleg Smolsky wrote: > Oh, funky. Sorry, I don't have a Mac to test. Do you have automated > builds going? > Only on Linux, unfortunately. Well, and the Solaris one that Monty runs. I suppose I should see about setting up an array of automatic builds on different

Re: [protobuf] Re: gcc4.4 fixes: std::tr1::unordered_map

2010-01-06 Thread Monty Taylor
Kenton Varda wrote: > On Wed, Jan 6, 2010 at 9:02 PM, Oleg Smolsky > wrote: > > Oh, funky. Sorry, I don't have a Mac to test. Do you have automated > builds going? > > > Only on Linux, unfortunately. Well, and the Solaris one that Monty > runs. I suppose

Re: [protobuf] Re: gcc4.4 fixes: std::tr1::unordered_map

2010-01-06 Thread Kenton Varda
On Wed, Jan 6, 2010 at 9:40 PM, Monty Taylor wrote: > Kenton Varda wrote: > > On Wed, Jan 6, 2010 at 9:02 PM, Oleg Smolsky > > wrote: > > > > Oh, funky. Sorry, I don't have a Mac to test. Do you have automated > > builds going? > > > > > > Only on Linux, un