[boost] Re: assert() replacement?

From: Greg Colvin (gcolvin_at_[hidden])
Date: 1999-08-30 14:32:03

From: Beman Dawes <beman_at_[hidden]>
> Greg Colvin wrote:
> 
> >From: Beman Dawes <beman_at_[hidden]>
> >> In private email, Kevlin Henney points out that use of assert() in
> >> boost headers violates the ODR (one-definition rule).
> >
> >How so?  Could you please elaborate?
> 
> NDEBUG can be set differently in different compilation units.  That
> causes an ODR violation if assert() is used by definitions
> (presumably in headers).  Quoting Bjarne, "This implies that assert()
> shouldn't be used in inline functions and template functions that are
> included in several translation units unless great care is taken than
> NDEBUG is set consistently."

Ah yes, I am remembering now.

Most projects I have been on have two seperate make targets, debug
and opt, which ensure that NDEBUG is either always on or always off
for a whole project, and select debug or opt libraries to link to.

> >I recall some discussion of assert and the ODR some years ago, and some
> >suggestions, I think from Andy Koenig, on how to fix it, but it didn't
> >happen, and I know longer remember the details.  I also recall that Mike
> >Vilot tried, and failed, to introduce a template-based alternative.
> 
> I don't remember the details either, but I think Mike's approach may
> have generated some code even when not active, and people wouldn't
> buy that.  Any attempts to fix it ran afoul of the ODR.  But I think
> the approach I suggested avoids those two problems.

I'm not convinced (see Valentin's comment) that it does, or can, but
I hope I'm wrong.

> >> ...
> >> Do others think that some such template base assertion approach is
> >> worth developing for boost?  Has anyone else tried to develop
> >> assert() replacements?
> >
> >There are four things I like about assert:
> >
> >1) Being a macro, it can report the location in the source where it triggers.
> 
> I think that is less of an issue now that most debuggers take you to
> the point of failure automatically, with the call stack available.

Many projects must be done without such tools.  Here at Oracle we are
true connoisseurs at sniffing stack traces, and source debugging usually
means attaching to a process with gdb or dbx.

> >2) Being a macro, it it easy to redefine it to throw, log, or
> whatever.
> 
> Yes, but we are back to trying to spell "undefined behavior"?

When it doesn't work, don't do it.

> >3) Being standard, it is always available.
> >4) Being standard, I have no qualms insisting that team members use it.
> >
> >We can fix 3 and 4 some years out, and a Boost template might be a start
> >in that direction, but 1 and 2 are harder to pull off.
> >
> >Regardless, I would hate to do anything that might discourage programmers
> >from using assert in C++ code.
> 
> If you rephrase that as "I would hate to do anything that might
> discourage programmers from using assertions in C++ code" then I
> certainly agree with you.  The question is "what form should those
> assertions" take?  Providing an alternative to assert() doesn't stop
> programmers from using assert() where they prefer it to the
> alternative.

No, I meant assert().  It is much easier to insist on a standard
facility than a home-grown one, and usually a good thing if error
handling is done consistently across a project.

> Sooner or later compilers are going to start diagnosing ODR
> violations.  At that point, people like me who have used assert() in
> headers are going to have a problem, I think.

Yes, but only if you try to mix and match, and only if the compiler
doesn't provide some way to relax the ODR for assert().