Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!apollo!mrst!sdti!mjy
From: mjy@sdti.UUCP (Michael J. Young)
Newsgroups: comp.lang.c++
Subject: Re: Disambiguating identifiers (was Re: ...Does C++ work with dbx...)
Keywords: C++, dbx, ctags
Message-ID: <272@sdti.UUCP>
Date: 26 May 88 14:40:00 GMT
References: <1158@daisy.UUCP> <7871@alice.UUCP> <269@sdti.UUCP> <10325@ulysses.homer.nj.att.com>
Reply-To: mjy@sdti.UUCP (0000-Michael J. Young)
Distribution: na
Organization: Software Development Technologies, Sudbury MA
Lines: 48

In article <10325@ulysses.homer.nj.att.com> jss@hector (Jerry Schwarz) writes:
>Do not assume that a native-code compiler is neccessarily better than
>one that uses C as an intermediate. While certain possibilities may
>be available to a native-code generator that are not possible for a
>compiler that uses C as an intermediate language, there is no
>guarantee that a native-compiler will be able to use this flexibility
>in a way that a debugger can use.  You have to look at any particular
>compiler/debugger system to be sure.

Agreed.  What I meant, but did not say very well, was that a native-code
compiler would hopefully be bundled with a debugger that understands the
language.  The problem of a reasonable C++ debugging environment is really
independent of the compiler.  I just expected that both issues would be
addressed simultaneously.

Unfortunately, my initial comment about native-code compilers confused the
real question that I had, which really has to do with the user interface of
C++ debuggers.

Frankly, unless we are willing to make major changes to the way linkers
work, I don't see how any compiler can avoid encoding type information
into public symbols.  So the problem of mangled identifiers will not go
away.  What I would like to see is a debugger that understands the
encoding scheme used by the compiler and translates identifiers automatically
so that the user never has to see the encoded form.  The syntax I see
as a user should look identical to the C++ source, so a breakpoint could
be set at function foo::foo(int), rather than __foo__ctor_I (or whatever).

Overloading makes it very difficult to specify an unambiguous reference.  It
seems to me that even window-oriented debuggers should allow the user to
TYPE an unambigous reference (rather than just point to the right spot in
the source).  The debugger should also be able to display breakpoint lists
without necessarily referring to line numbers or mangled identifiers.
Session logs and script files also present a problem, although I suppose
someone could use the argument that non-interactive uses don't have to be as
intuitive and user-friendly. 

My initial question was how existing C++ debuggers (such as the one for
GNU C++ or Oregon Software C++) handle this.  Perhaps a better question
is what would the user community like to see in future debuggers?

Jonathan Shopiro sent me mail describing how pi works.  This sounds like
a great start in the right direction.  I just wish I could get it.
-- 
Mike Young - Software Development Technologies, Inc., Sudbury MA 01776
UUCP     : {decvax,harvard,linus,mit-eddie}!necntc!necis!mrst!sdti!mjy
Internet : mjy%sdti.uucp@harvard.harvard.edu      Tel: +1 617 443 5779
"Bill & Opus in '88" -- Consider the alternatives!