Something like this may have been proposed before, but I haven't been
able to regularly followed this group.

One of the problems in writing class libraries for c++ involves providing decent
diagnostic information for run time errors invoving misuse of the class
interface. There is no GOOD manner of providing the diagnostic information for
where the method or operator was called from, due to overloading, the method of
accessing the class method and operators. The method of providing this information
in std c would be to place a macro definition in a header file like this:

 int foo(const char *__CalledBy,int __CalledAt,int param)
 #define foo(param) foo(__FILE__,__LINE__,param)

But you can't do this very nicely for class methods, overloaded functions,
operators, etc. In c++


But it seems to me the compiler could easily add __FILE__,__LINE__ as a set of
"hidden" parameters to EVERY function call, and they would be available in EVERY
function. This would make it a lot easier for the class to provide information
about  where the problem was caused.


In addition, the compiler could also add a string constant __Id, which would
contain the variable name associated with the object being created, to the
constructor call of a class in a "hidden" fashion, so that this could be provided
later int the diagnostic information if this is saved.


This all seems relativly simple (chuckle) for the compiler to provide, but I have
been wrong before :)

Andrew Staniszewski
staniszewski@mayo.edu

In <1993Feb17.141606.1536@bmw.mayo.edu>, Andrew Staniszewski writes:

|> But it seems to me the compiler could easily add __FILE__,__LINE__ as
|> a set of "hidden" parameters to EVERY function call, and they would be
|> available in EVERY function. This would make it a lot easier for the
|> class to provide information about where the problem was caused.

|> In addition, the compiler could also add a string constant __Id, which
|> would contain the variable name associated with the object being
|> created, to the constructor call of a class in a "hidden" fashion, so
|> that this could be provided later int the diagnostic information if
|> this is saved.

|> This all seems relativly simple (chuckle) for the compiler to provide,
|> but I have been wrong before :)

This would be very simple for the compiler to provide, but think of
the cost in run-time overhead.  And it's a cost that you would have to
pay even if you didn't use the feature.

Perhaps a better idea would be a library function which does a stack
walk-back.  (This cannot be done in an implementation independant
manner, so each implementation would have to provide its own.)  This
routine would only be called when a pre-condition wasn't met, so
normally would only have an adverse effect on code size.  If the
routine was really intelligent, it could exploit debugging information
in the executable to give you a symbolic walk-back.
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung

stan@sabaac.NoSubdomain.NoDomain (Andrew Staniszewski) writes:

>But it seems to me the compiler could easily add __FILE__,__LINE__ as a set of
>"hidden" parameters to EVERY function call, and they would be available in EVERY
>function. This would make it a lot easier for the class to provide information
>about  where the problem was caused.

Yes, it would be easy, but I stongly doubt that programmers would like
the overhead of two extra parameters to every function in the entire
program.  If you want the information to be passed, declare the
parameters yourself and pass them.
--

Steve Clamage, TauMetric Corp, steve@taumet.com

In article <1993Feb17.141606.1536@bmw.mayo.edu> staniszewski@mayo.edu writes:
> [...]
>But it seems to me the compiler could easily add __FILE__,__LINE__ as a set of
>"hidden" parameters to EVERY function call, and they would be available in EVERY
>function. This would make it a lot easier for the class to provide information
>about  where the problem was caused.
> [...]

The problem with this would be all the run-time overhead involved.
It seems to me that it would be much better to have an option to
the linker which would include the relevant parts of the the symbol
table as part of the load image, then have a library which could
use this information to do stack traces in a manner similar to dbx,
etc.  This would incur no run-time overhead except during the
initial load (and on a VM system, not even that), yet would allow
the functionality desired.

Note that this is not a standards issue, but an implementation issue.
Followups to comp.lang.c++.