Re: FYI: removing the libstdc++ pretty-printers

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Tom> While that is not super friendly, I think it is pretty important that
Tom> we maintain the printers (1) alongside the code they work with, and
Tom> (2) in a single place.

Pedro> That's an idealistic goal, that does that assumes that the printers
Pedro> will always be written and cleaned up for the top of gcc head internals?

Yes.  The idea is that they will be maintained alongside libstdc++.
Ideally, a libstdc++ implementation change would not be complete
unless the corresponding printer was updated as well.

Pedro> I'd like to raise a few questions just for thought.  Will the
Pedro> printers over time be adjusted to work with a variety of
Pedro> libstdc++ versions?

Yes.  We put the printers into the namespace "libstdcxx.v6".  When
libstdc++ bumps its version number, we will rename this to
"libstdcxx.v7" and rewrite the printers as needed.  The current design
is also multi-inferior-proof.

Exactly how this is managed for other applications and libraries is
really up to those maintainers.

Pedro> E.g., will the same std::string printer work mostly ok with
Pedro> different versions/builds of libstdc++, like, e.g., versions
Pedro> that use the empty string optimization, others that don't
Pedro> (e.g., built with enable-fully-dynamic-string); debug versions
Pedro> vs release versions.

I'm not really a libstdc++ expert.  The generic answer is that a lot
of information is available to the printers.  If there are different
ways to configure a given libstdc++, I don't see why the printers
can't dynamically adapt.  (Or, they could also have configure
substitutions or whatever -- but I think it would be preferable to
avoid that.)

Pedro> Is it expected that printers for different libstdc++ vendors
Pedro> end up being similar in many aspects, and thus could share
Pedro> python code?

I am even less of an expert about non-GNU implementations of the
standard c++ library -- in fact I have never looked at one.  I doubt
that these printers would work for some other implementation, though
they could if the two implementations share code.  The printers are
dependent on the exact details of the implementation of classes; they
often reimplement core class logic.

This sort of thing is why I think each library has to be responsible
for its own printers.

Pedro> From a different angle: What is expected to change more often in the
Pedro> coming times?  The internal details of the classes we're writing
Pedro> printers for; or, the printers themselves, and the details of the
Pedro> python API?

For libraries, there is no rule.  libstdc++ is cautious about changes,
but that is not true for all interesting libraries.

As to the gdb Python API, we have been quite cautious about pushing
things from Archer into CVS gdb precisely due to API constraints.  We
don't intend to break the existing API.  Python's dynamic nature helps
here, but we've also done a fair amount of tweaking to try to ensure
that the existing API will be good for a long time.

Pedro> Who are expected to change these files more often in the next
Pedro> year(s)?  gcc hackers?  or archer/gdb hackers?  I assume most
Pedro> pretty printer hackers don't have/need to hack on gcc or have
Pedro> gcc commit rights.  Who (which project) is better suited to
Pedro> test the printers?

Yeah, testing is still a problem.

I don't know who will change the printers more in the near future, but
I do think that over the long haul, the only good place for a given
suite of printers is inside the source tree of the application or
library they work with.

This is my working assumption because I think there will be many
printers in the wild (many more than we would ever want to ship in
gdb), and also because gdb's release schedule does not synchronize
with the schedule of anything else.

In the short term this may cause some subset of users some difficulty.
I tend to think that this subset is small.

Tom