Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!alice!shopiro
From: shopiro@alice.UUCP
Newsgroups: comp.lang.c++
Subject: Re: Question: Does C++ work with dbx and ctags?
Summary: C++ and dbx can be used together
Keywords: C++, dbx, ctags
Message-ID: <7871@alice.UUCP>
Date: 15 May 88 17:56:22 GMT
References: <1158@daisy.UUCP>
Distribution: na
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 34
Posted: Sun May 15 13:56:22 1988

In article <1158@daisy.UUCP>, cwc@daisy.UUCP writes:
> I have no hand-on experience with C++, but I am sort of
> convinced that C++ is a better C for its stronger type
> checking and object-oriented features.  However, I do
> have two concerns in jumping to C++ at this moment:
> 
> 1. Is there any dbx (or similar source-level debugger)
>    that understands C++?
I regularly use dbx to debug C++ programs.  Setting breakpoints on line
numbers works fine.  In order to set breakpoints on functions, or inspect
the values of variables, you need to know the ``mangled'' version of
the name you want to reference.  I use nm to generate a namelist of the
a.out, and keep it in another window so I can paste the names into the
debugging session.  This is much easier than figuring out what the name
should be and typing in your guesses.  I also use the ``dump'' and
``whatis'' commands of dbx to find names of automatic variables and
structure members.  A feature of the compiler that makes debugging
easier is the ``+d'' switch which inhibits inline function expansion,
so that breakpoints can be inserted in such functions.  (Try that with
a macro :-)).

>   Or do we have to debug the C output from the C++ translator?
I never look at the generated C code for this purpose.  This corresponds
to looking at the assembly code generated by the C compiler.

>   How do we debug C++ program in the absence of a good source-level
>    debugger ?   Any ways better than printf()?
See above, but don't disparage printf().  The next version of C++ will
have a canonical ``demangler'' that can be incorporated into future
debuggers.
-- 
		Jonathan Shopiro
		AT&T Bell Laboratories, Murray Hill, NJ  07974
		research!shopiro   (201) 582-4179