Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!alice!ark
From: ark@alice.UucP (Andrew Koenig)
Newsgroups: net.lang.c++
Subject: Re: Standard C routines calling C++ (non-member) functions
Message-ID: <6114@alice.uUCp>
Date: Fri, 26-Sep-86 12:17:52 EDT
Article-I.D.: alice.6114
Posted: Fri Sep 26 12:17:52 1986
Date-Received: Tue, 30-Sep-86 03:25:22 EDT
References: <1221@uw-june>
Organization: Bell Labs, Murray Hill
Lines: 21

> I have an unrelated (possibly naive) question.  I am using dbx
> to debug my code, and I was rather surprised to find that
> dbx can relate C++ statements (not those in the ..c files)
> to the pc, so I can smoothly trace execution from the debugger.
> I have to do all the name translation by hand (ie. Class::function
> becomes Class_function, prepending _auto_ to most things, etc...),
> but dbx is able to map my .c source code to the executable so
> I can trace through things and see the original C++ code.
> Since it is really the ..c files that are being compiled with
> /bin/cc, how is dbx able to do this??  This is not a complaint.

Cfront uses the same mechanism the C preprocessor uses to communicate
line numbers to the C compiler proper.

In other words:  when you say  #include "foo.h"  the C compiler knows
to give you error messages referring to foo.h rather than to your
source file, even though all it actually sees is one long stream of
text.  This happens because the C preprocessor inserts magic cookies
into its output saying "the following stuff comes from line p of file q."

Cfront uses exactly the same mechanism.