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

[Pedro Alves <pedro at codesourcery dot com>]

On Monday 01 June 2009 17:41:40, Tom Tromey wrote:
> While that is not super friendly, I think it is pretty important that
> we maintain the printers (1) alongside the code they work with, and
> (2) in a single place.

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

I'd like to raise a few questions just for thought.  Will the printers over
time be adjusted to work with a variety of libstdc++ versions?  E.g., will the
same std::string printer work mostly ok with different versions/builds of
libstdc++, like, e.g., versions that use the empty string
optimization, others that don't (e.g., built with enable-fully-dynamic-string);
debug versions vs release versions.  Or is it expected that there will be
printer forks for all these cases and versions?  Probably not that important,
but still: Is it expected that printers for different libstdc++ vendors end
up being similar in many aspects, and thus could share python code?

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

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

-- 
Pedro Alves