libdw C++ interface

[Roland McGrath <roland at redhat dot com>]

I've reorganized a bit to fix a braino I'd had, and added a big overview
comment to libdw/c++/dwarf.  

I added a testing option to dwarfcmp, and made run-dwarfcmp-self.sh also
test that mode.  This test is extremely slow now, but that is normal.
Under -T, dwarfcmp does the comparison work a dozen extra times, plus the
pure-memory object construction, so it's doing more than 12x the work for
each run.  

The self-test passes, which is our second milestone (DwarfTasks 2.5),
though I have not yet done the exhaustive test run.  (My spare machine had
a flaky disk, so I've just put different spare disks in it, reinstalled and
started the extraction from scratch again.)

Benjamin, the easy way to get the code is:

	git clone git://git.fedorahosted.org/git/elfutils.git 
	cd elfutils
	git checkout -b dwarf origin/dwarf
	git pull # Repeat later to get any new changes.

If you want to build it, do 'autoreconf -f -i'.  Then normal conventions,
--enable-maintainer-mode recommended.

See libdw/c++/dwarf and please give me feedback on the fundamental API.
This code is very prototypey and many corners are not finished.  I am not
yet worrying about where the template instantiations should be compiled and
all that.  (If you tell me about best practices for that stuff, I will file
it away for a bit later.  But I am not going to think about it real soon.)

I think the big comment explains the basic thinking behind the API style.
Much of the template-heavy stuff is motivated by comparing and copying
between the input virtual objects and the output pure-memory objects.  The
writer implementation will involve another one or two such class trees that
are likewise copyable from these.

The only test case using the classes so far is src/dwarfcmp.cc, which uses
the input iterators and comparison operators.  With -T, it tests the
templatized output constructors from input iterators, and the output
comparison operators.

The organization of the classes is what I think makes sense, and that seems
(to me) to fit in maximally with the STL container model.  (I tried to make
all my virtual containers look template-compatible with the STL containers.)

The details of how I implemented all the C++ magic is entirely just what I
got to work.  Plenty of it didn't so much especially make sense to me, as I
just banged against what it might want until the compiler finally shut up.
In particular, things like the specificity of the template variants of
things and the ramifications of template operator functions vs template
operator methods are almost entirely mysterious to me.  Anything that seems
insane and like it should be done another way, probably is and should be.
Tell me.

There are some places where I had to make a constructor public because of
some template weirdness generating errors from system header files.  I
don't understand those at all.

The most interesting piece of the interface is not there yet (attr values).
So far we only have the containers, a full skeleton with no meat.
But I'm pretty happy with the results so far, if not the readability of the
class definitions.  The test_writer code in dwarfcmp is sure readable though!

I feel reasonably confident that miscellaneous application code digesting
the data would be fairly easy to write (and read) now, just in that the
container interfaces seem "simple".  I'd like a reality check on that
feeling.  (For actual consumers, we are missing all the interesting
tree-oriented layer of stuff that would be built on this basic input model.)

All advice welcome.


Thanks,
Roland