Boost logo

Boost :

Subject: Re: [boost] [utility] [assert] Proposal for a new assert macro which stores the failed values ("informative assert")
From: Krzysztof Czainski (1czajnik_at_[hidden])
Date: 2013-06-07 06:16:49

2013/6/5 Andrey Semashev <andrey.semashev_at_[hidden]>

> I would very much prefer BOOST_ASSERT to stay as small and lightweight as
> possible and equivalent to the standard assert macro by default. One reason
> we're not using BOOST_ASSERT_MSG much is that it uses streaming expressions
> to format the error message, which turns out to be too heavy in some places
> (e.g. it prevents small functions from inlining and fragments the hot code
> too much). Please, make a new macro for this feature.

 2013/6/5 Krzysztof Czainski <1czajnik_at_[hidden]>

> >I second the problem with BOOST_ASSERT_MSG. And I'm thinking it can be
> > trivially worked around: BOOST_ASSERT_MSG could be (conditionally)
> defined
> > like so:
> >
> > #define BOOST_ASSERT_MSG( expr, msg ) assert( (expr) || !msg )
> > #else
> > ...
> > #endif

 2013/6/7 Viktor Sehr <viktor.sehr_at_[hidden]>

> I might get something wrong, but why not simply #define BOOST_ASSERT_MSG(
> expr, msg ) assert( expr)?
> The point of the msg-part, to me, is to serialize variables?

I see.

My motivation comes from using boost::array::operator[]:

reference operator[](size_type i)
  BOOST_ASSERT_MSG( i < N, "out of range" );
  return elems[i];

I experienced problems with this function, which Andrey described above.
And my proposition of simplifying BOOST_ASSERT_MSG would work around this,
but I didn't think of more complicated use cases.

So should there be a guideline to use the BOOST_ASSERT( expr || !"msg" )
idiom instead of BOOST_ASSERT_MSG, when msg is only a string literal, or
how should this problem be addressed?


Boost list run by bdawes at, gregod at, cpdaniel at, john at