Why not use std::tr1::hash<std::string &> ?
I guess I didn't know it was there. Feel free to fix that.
Aha. Sorry I was again confused about which hash function was being
used. But indeed we are using the hashed_value_type::hasher, not the
A hashed_value_type of course uses its inner value_type::hasher once to
compute the value stored in _m_hash.
That all makes sense, except for the throwing away. That seems
but might be the best we can do when reusing the sdt unordered_set?
Yeah, C++ loves to copy objects. We could make the value_set store
everything indirected through pointers, though the STL implementation
already has layers of indirection in its allocation. I'm not really
sure at all how that would fit into the compute-time/memory-use
tradeoffs. The copier::string_cache bit made a huge performance
difference, though. Having an actual class system to use should mean
we can change all this later with only touching subr::value_set and
maybe a bit of the collector. But I'm not real sure (except for
strings) how to compute the correct hash of the dwarf_output_collector
internal representations to search for without wholly instantiating
one of its objects.
> All of this stuff is essentially uninteresting. It's just
the layers of
> C++ hooey to keep a hash table for each value_something type, and return
> the const value_something * pointing into that hash table.
Yeah, sorry that I keep getting lost in the uninteresting stuff.
Poke more often with more questions, no question is stupid to ask.
I'm also sorry that I've made all the "simple" bits so obtuse. I do
want to get more eyes reviewing all that and suggesting better ways to
make it more clean or more clear. But I've figured we shouldn't
really let that eat time before we have hashed out the meat of the big
algorithmic issues at the higher levels. Those require the real
smarts, not just teasing out C++ wonkery and profiling.