[boost] Re: ctassert ... macros :-)

From: Andy Glew (glew_at_[hidden])
Date: 2000-01-03 18:30:19

> > I doubt you will get much support for any solution that requires
> > macros.

Mind if I uplevel this issue a bit?

Preprocessor macros are widely deprecated.
Beman frequently deprecates them.

Although I concur with deprecating macros, my own programming
would be much, much, more difficult without macros, with issues relating
to debugging and local context.

Brief
====

Debug Info
-------------

E.g. in discussion of a replacement for the standard C macro assert(),
Beman suggested that a non-macro solution was acceptable.
Admitting that this lost the ability for the new assert to report
__FILE__, __LINE__, and the text of the failed assertion,
Beman said something like "most C++ users use an IDE,
so this information is not necessary".

(Beman: I hope this a fair characterization.)

PROBLEM: GNU GCC depends on __FILE__ and _LINE__ information in assertion
error messages, etc., to bring the user to the point of an error.

This is important in the compile/edit/debug cycle.
It is also especially important for long running production programs.

I'll go so far as to say that any "new standard" assert() or ctassert()
created by the Boost group will be absolutely useless to me, or to
programming groups I will be involved with, if they cannot embed
__FILE__ and __LINE__ in the output.  If the "new standard" does not
support __FILE__ and __LINE__, then I and my coworkers will have
to create our own macro wrappers that add this info; if multiple groups create
such wrappers that are similarly named but not identical, it will be an obstacle
to code sharing.

Note: if it were possible to indicate that the default value of a function
parameter should be the __FILE__ and __LINE__ at the point of
invocation rather than the point of definition, this objection would be
eliminated.

Local Context
----------------

This is more speculative:

I find that I continue to use macros rather than C++ inline functions
in situations where, in other languages (Perl, Pascal (Delphi), LISP)
I would use a nested function, with either lexical or dynamic binding.

Alternately, to accomplish the same effect in C++ I find that I often create
local class definitions with functions defined in place - the C++
approximation of lambda functions. See discussions of lambda function
parameter binding on comp.lang.c++.moderated.  However, lambda
functors are considerably less convenient that macros, so I continue
to use macro shorthands.

I mention this only because some folk like Beman may have influence over
language directions --- or because

Extra Detail and Verbosity
===================

Debug Info
-------------

E.g. in discussion of a replacement for the standard C macro assert(),
Beman suggested that a non-macro solution was acceptable.
Admitting that this lost the ability for the new assert to report
__FILE__, __LINE__, and the text of the failed assertion,
Beman said something like "most C++ users use an IDE,
so this information is not necessary".

(Beman: I hope this a fair characterization.)

I challenge this statement: certainly, it does not apply to me,
and I suspect it may not overall be true.

++ I do the vast majority of my programming using GCC / G++.

    The combination of GCC and GNU EMACS may or may not be
    called an IDE, but it certainly does depend on having
    __FILE__:__LINE__ prepended to the beginning of every
    error message. When I type a key sequence that executes
    the EMACS LISP
        (make "make -k test && ./test")
    to compile and run my test suite, EMACS parses the output
    and can only take me to lines where issues are flagged by
    like
        test-header.cc:34 some error
    This applies to both compile time and run time (assert) errors.

    I don't need file:lineno if I run withoin the debugger, but
    I don't run makes within the debugger.  UNIXes do not seem to
    have the sort of debug hook that Windows has, e.g. invoking
    Dr. Watson or VC++'s IDE when an error is encountered.
    (Or, equivalently, some UNIXes may have such hooks, but
    they are not uniformly available; people who worry about
    portability and uniformity between different systems can't
    rely on it.)

++ I could continue on to argue that GCC is very important.

    Anyway, my challenge: I wonder if anyone has statistics as to how many
    people use any particular C or C++ compiler?

    I would not be surprised if GCC exhibited an absolute preponderance.