It looks like unordered_map or unordered_set is not behaving correctly (e.g.
not finding matching keys when they are present) but I can't really tell
just from that output.
On Mon, Jul 20, 2009 at 11:53 AM, vikram patilvik...@gmail.com wrote:
In previous attempt small test worked but was not
In previous attempt small test worked but was not able to work with
protocol buffer source code.
I tried one more thing as
#if deinfed (MISSING_HASH_MAP) defined (__xlC__)
#define hash_map std::tr1::unordered_map
google/protobuf/unittest.proto:85:37: Expected ;.
Kenton Monty,
I added hack as followes in the hash.h
// File changed .
#if defined(HAVE_HASH_MAP) defined(HAVE_HASH_SET)
#include HASH_MAP_H
#include HASH_SET_H
#elif defined (__xlC__)
#define MISSING_HASH
#include unordered_map
#include unordered_set
#else
#define MISSING_HASH
It looks like your implementation of hash_map is not working correctly --
all lookups are failing. You might try writing a little test for hash_map
itself that would be easier to debug.
On Tue, Jul 14, 2009 at 6:27 PM, vikram patilvik...@gmail.com wrote:
Kenton Monty,
I added hack
I have found out that with new xlC versions like 8.X onwards hash_map
like functionality is supported but different name as unordered_map.
So it there any way you can to use this container without modifying
much of the code. In the code hash_map is used in many places. So it
needs to be replaced
google/protobuf/stubs/hash.h already contains some hacks for hash_map. To
support unordered_map, all we'd have to do is add another hack there which
defines hash_map to be a subclass of unordered_map. Subclassing effectively
functions as a template typedef here.
I would rather not replace the
And yes, I'd love a patch. :)
On Mon, Jul 13, 2009 at 5:22 PM, Kenton Varda ken...@google.com wrote:
google/protobuf/stubs/hash.h already contains some hacks for hash_map. To
support unordered_map, all we'd have to do is add another hack there which
defines hash_map to be a subclass of
My attempt to use default hash_map implementation in source leads to
infinite loop. So I tried to links source with STLport 4.6.1 version
for AIX.
For XLC i provided tempinc option to create default directory for
template instantiation. But I am not able to compile it.
This looks like a problem with the STL implementation. Sorry, I don't know
what to do about this.
On Tue, Jun 30, 2009 at 5:32 PM, vikram patilvik...@gmail.com wrote:
My attempt to use default hash_map implementation in source leads to
infinite loop. So I tried to links source with STLport
Hey Kenton,
This is compilation without STL implementation . I am assuming
that if hash_map does not exist , google protocol buffer emulates
hash_map. I am pasting 3-4 instances of stack where protoc is in
infinite loop
#0 0xd1cfdc60 in
Can you do a build with debug info to get line numbers?
On Fri, Jun 26, 2009 at 1:29 PM, vikram patilvik...@gmail.com wrote:
bash-3.00$ gdb src/.libs/lt-protoc
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
@Kentan
I built with debug info and got following stack trace .
location of compiler is at /usr/vacpp/bin if its not by default.
#0 0xd1afa248 in
12 matches
Mail list logo
