public inbox for archer@sourceware.org
 help / color / mirror / Atom feed
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

             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).