But having all hashes (local and global) in pending_entry would be
beneficial. Currently however we try to drop the pending_entry as soon
as possible whenever we finalize an entry. So maybe we should move them
both into entry. Also because entry already has the parent which is used
in the tracker for the matching algorithm.
The die_info_pair is the place that makes sense to me for storing more
information about the final state of things. That is, either in
dwarf_output::debug_info_entry or in die_info. Those live permanently in
the collector. That's where you benefit from having full hash values on
hand to compare, because when you need to do comparisons it's against
existing objects already final in the collector and found there via hashes.
If you had them in copier::entry, how would you ever find them there when
you need them?
die_info also has _m_parent, which is what's used by copier::tracker.
Yes, again I admit that the way this evolved was mainly because of
way I was most easily able to change the code. Ideally I would have
added the local hash code to the attributes themselves, but it seemed
dwarf_data::value_reference, but I really couldn't figure out how things
got initialized correctly in that case. And it wasn't clear to me
whether the concept of local hashes really made much sense to any other
subclass/template instance of that type. I'll make sure the final
algorithm used for the hash calculation will be documented in the code.
It's certainly possible to do it the other way. You just don't break up
the hash calculation along the lines of the attributes_type/children_type
objects. Instead, do it all at the entry level.
> As I did things originally, the
> (really dwarf_data::attr_value::reference) is not meant to be used on
> something that isn't really final and placed.
I have to admit that I find this slightly confusing, since it seems to
depend on which template instance is being used whether or not
reference() works or not. Although I now see why that would be in the
implementation. It kind of breaks the interface abstraction.
No, the interface abstraction is for objects whose construction has been
finished. If you use dwarf_output::attr_value::reference on a dwarf_output
object that actually exists, then it works just fine. It's only trying to
use that while you are still inside its own constructor that is a problem.
Yeah, I actually had wanted to do a trick like that in the
attributes_type do_hash () function, but I didn't know how to get at the
_m_value of the attr_value there. Which is also why I ended up using
what_space to detect whether the attribute was a reference value or not.
You can just use av->_m_value directly. If you can't, then you just
have to add:
friend class dwarf_output::attributes_type;
into the 'class attr_value' definition.
I admit that my c++ typing knowledge fails me again in this example.
How can it be that this template variant of reference () returns ...
while the dwarf_data::attr_value::reference method is defined as
inline const die_ptr &reference () const with typedef typename
impl::debug_info_entry::pointer die_ptr; Since impl is dwarf_output, it
seems somewhat curious that this method is allowed to change the type of
the return value. Again this kind of breaks my vision of the abstraction
You have the wrong idea of how the abstraction binding works. A template
is not like a base class. The various dwarf* classes are "template
compatible". What that means is that you can use the methods of the same
names in the same ways. Put another way, it means the same method in each
of two implementations will have return types that are template-compatible.
No it didn't directly answer my question of "how the hell do
I trick c++
into doing what I want in this case", but it does show me I should
concentrate on moving all (local) hashing logic into the (pending) entry
which can rely on the input die tree and stay as far away from anything
that could become part of pending_dwarf as I can for now :)
Well, I can't tell if we are really making progress here or not.
But I'll hope.