[boost] Re: assert() replacement?

From: Kevlin Henney (Kevlin.Henney_at_[hidden])
Date: 1999-08-31 03:55:00

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.

   It's not to say that one can't resolve the issue, but the question is,
   do we wish to impose a single development style on others just because
   they wish to use polymorphic_cast or numeric_cast? I would hope not.

   To get it right, we would have to mandate that all of their source code
   (and that can be a lot) was compiled consistently w/ or w/o NDEBUG set
   -- goodbye to the benefits of separate compilation :-( -- and that this
   includes any libraries they themselve used, which may or may not be
   under their control. This level of intrusion would be a heavy price to
   pay for using these casts!

> 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().

   It doesn't really matter whether or not a compiler diagnoses ODR, you
   can still get ODR problems: it is the violation not the diagnosis that
   is the root of the problem. I have come across a couple of instances
   where ODR violation has lead to problems -- the absence of ODR diagnosis
   has just meant that it took longer to find, but it didn't mean the
   problem wouldn't arise.

   I am not sure that relaxing ODR for assert is an issue: it has no
   linkage! The issue arises for functions that use it, and as far as I can
   see there is no standard way one could do it. The last thing one would
   want to see in the standard is an extra paragraph at the end of section
   3.2 stating "BTW, anything that uses assert is exempt from all of the
   above. The behavior is implementation defined." :-}

   Kevlin