From: Eli Zaretskii <eliz@gnu.org>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [doc patch] whatis vs. ptype - the difference
Date: Fri, 15 Jul 2011 14:17:00 -0000 [thread overview]
Message-ID: <8339i7j4ng.fsf@gnu.org> (raw)
In-Reply-To: <20110712183130.GA15349@host1.jankratochvil.net>
How about the text below?
The only nit that I'm not yet sure about is at the end: "typedefs
... at the pointer target". What do you mean by that? can you show an
example?
@item whatis [@var{arg}]
Print the data type of @var{arg}, which can be either an expression
or a name of a data type. With no argument, print the data type of
@code{$}, the last value in the value history.
If @var{arg} is an expression (@pxref{Expressions, ,Expressions}), it
is not actually evaluated, and any side-effecting operations (such as
assignments or function calls) inside it do not take place.
If @var{arg} is a variable or an expression, @code{whatis} prints its
literal type as it is used in the source code. If the type was
defined using a @code{typedef}, @code{whatis} will @emph{not} print
the data type underlying the @code{typedef}. If the type of the
variable or the expression is a compound data type, such as
@code{struct} or @code{class}, @code{whatis} never prints their
fields or members. It just prints the @code{struct}/@code{class}
name (a.k.a.@: its @dfn{tag}). If you want to see the members of
such a compound data type, use @code{ptype}.
If @var{arg} is a type name that was defined using @code{typedef},
@code{whatis} @dfn{unrolls} only one level of that @code{typedef}.
Unrolling means that @code{whatis} will show the underlying type used
in the @code{typedef} declaration of @var{arg}. However, if that
underlying type is also a @code{typedef}, @code{whatis} will not
unroll it.
For C code, the type names may also have the form @samp{class
@var{class-name}}, @samp{struct @var{struct-tag}}, @samp{union
@var{union-tag}} or @samp{enum @var{enum-tag}}.
[...]
Contrary to @code{whatis}, @code{ptype} always unrolls any
@code{typedef}s in its argument declaration, whether the argument is
a variable, expression, or a data type. This means that @code{ptype}
of a variable or an expression will not print literally its type as
present in the source code---use @code{whatis} for that. Any
@code{typedef}s in fields of a @samp{struct} or at the pointer target
are always preserved by @code{ptype}.
next prev parent reply other threads:[~2011-07-15 9:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-12 19:20 Jan Kratochvil
2011-07-12 20:28 ` Eli Zaretskii
2011-07-12 20:38 ` Jan Kratochvil
2011-07-12 20:43 ` Eli Zaretskii
2011-07-12 20:30 ` Tom Tromey
2011-07-15 14:17 ` Eli Zaretskii [this message]
2011-07-15 18:07 ` Jan Kratochvil
2011-07-19 13:52 ` Pedro Alves
2011-07-26 2:58 ` ping: " Jan Kratochvil
2011-07-26 8:36 ` Eli Zaretskii
2011-07-26 18:11 ` Jan Kratochvil
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=8339i7j4ng.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
/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