From: Roland McGrath <roland@redhat.com>
To: Project Archer <archer@sourceware.org>
Subject: feature idea: type nicknames
Date: Fri, 03 Jul 2009 00:21:00 -0000 [thread overview]
Message-ID: <20090703002049.C49F1404FD@magilla.sf.frob.com> (raw)
So, a thing I'm looking at all day and all night today looks like this:
21.9 y 0x0000000000437a0e in talker<elfutils::dwarf_edit, elfutils::dwarf_output>::mismatch(std::_Rb_tree_const_iterator<std::pair<int const, elfutils::dwarf_data::attr_value<elfutils::dwarf_edit, elfutils::dwarf_data::value<elfutils::dwarf_edit> > > >, std::_Rb_tree_const_iterator<std::pair<int const, elfutils::dwarf_data::attr_value<elfutils::dwarf_edit, elfutils::dwarf_data::value<elfutils::dwarf_edit> > > > const&, std::_Rb_tree_const_iterator<std::pair<int const, elfutils::dwarf_data::attr_value<elfutils::dwarf_output, elfutils::dwarf_output::value_wrapper> > >, std::_Rb_tree_const_iterator<std::pair<int const, elfutils::dwarf_data::attr_value<elfutils::dwarf_output, elfutils::dwarf_output::value_wrapper> > > const&)
(At the moment, I'm just talking about the long hoary type names.
But, yes, that is location 9 of breakpoint 21. Breakpoint 5 has 15 locations.)
So, to start with, some of that is STL internals hooey that I, poor lowly
programmer, am not responsible for. This here:
std::_Rb_tree_const_iterator<std::pair<int const, elfutils::dwarf_data::attr_value<elfutils::dwarf_edit, elfutils::dwarf_data::value<elfutils::dwarf_edit> > > >
appears in *my* code nowhere in a form longer than:
std::map<int, elfutils::dwarf_data::attr_value<elfutils::dwarf_edit, elfutils::dwarf_data::value<elfutils::dwarf_edit> > >::const_iterator
Now that is not so short, but let's stick with the STL part for the moment:
std::map<a, b>::const_iterator
Now leaving aside how ugly a and b are to print, that is pretty nice.
What makes sense to me is that the STL pretty printer module can also
have "type name pretty-printers". This would let them match
std::_Rb_tree_const_iterator<...> and pick apart the ... to discern
what proper std::some<...>::const_iterator to call it.
Now let's consider the same thing for my own program. Say I don't
even know Python, but I'm all template-happy with my C++ and I really
do think I know what I'm trying to do, but my eyes are bleeding.
(gdb) whatis it
type = elfutils::dwarf::skipping_wrapper<elfutils::dwarf::debug_info_entry::raw_attributes_type, elfutils::dwarf::attribute, elfutils::dwarf::attribute, elfutils::dwarf::skip_sibling>::const_iterator
(gdb) callthat dieptr
dieptr = elfutils::dwarf::skipping_wrapper<elfutils::dwarf::debug_info_entry::raw_attributes_type, elfutils::dwarf::attribute, elfutils::dwarf::attribute, elfutils::dwarf::skip_sibling>::const_iterator
(gdb) p &it
$27 = (dieptr *) 0x1234567
(gdb) thank you, oh thank you
Labor creates all wealth.
(gdb)
For extra points:
(gdb) whatis it
type = const elfutils::dwarf::skipping_wrapper<elfutils::dwarf::debug_info_entry::raw_attributes_type, elfutils::dwarf::attribute, elfutils::dwarf::attribute, elfutils::dwarf::skip_sibling>::const_iterator &
(gdb) callthat const dieptr &
dieptr = elfutils::dwarf::skipping_wrapper<elfutils::dwarf::debug_info_entry::raw_attributes_type, elfutils::dwarf::attribute, elfutils::dwarf::attribute, elfutils::dwarf::skip_sibling>::const_iterator
(gdb) whatis it
type = const dieptr &
(gdb)
I imagine it might actually be called "set print typename dieptr = it"
or something.
This command idea dovetails with what I think library pretty printers
like STL's should implement somehow anyway.
But the "type-only convenience" variables idea could be another
approach for this casual kind of use:
(gdb) set $dieptr = typeof(it)
(gdb) p &it
$227 = ($dieptr *) 0x1234567
(gdb)
However, having only $names by nature might not be the thing people
like the most.
Getting back to the basic "type-name pretty-printing": I think it
would make sense to have some heuristic defaults along with any
library-specific hooks. Like maybe "shortest public name" among
typedefs all resolving to the same thing, etc.
Thanks,
Roland
next reply other threads:[~2009-07-03 0:21 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-03 0:21 Roland McGrath [this message]
2009-07-03 16:34 ` Tom Tromey
2009-07-03 19:38 ` Roland McGrath
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090703002049.C49F1404FD@magilla.sf.frob.com \
--to=roland@redhat.com \
--cc=archer@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).