Gennaro Prota wrote:
> Just that Borland won't warn on BOOST_INVARIANT(false). Admittedly
> not a big one :-)
This warning can be configured away simply by purposely accessing a non-constant
variable or calling an inline function:
inline bool force_non_constant() { return true; }
if (force_non_
--- Daniel Frey <[EMAIL PROTECTED]> wrote:
> Gennaro Prota wrote:
> > On Thu, 8 May 2003 15:06:02 +0300, "John Torjo" <[EMAIL PROTECTED]>
> > wrote:
> >
> >>Unfortunately, we can't use the do-while(0) idiom, since we don't know when
> >>while(0) will be ;-)
> >>
> >
> > Oops, no. That's not the p
Gennaro Prota wrote:
On Thu, 8 May 2003 15:06:02 +0300, "John Torjo" <[EMAIL PROTECTED]>
wrote:
Unfortunately, we can't use the do-while(0) idiom, since we don't know when
while(0) will be ;-)
Oops, no. That's not the problem. The problem is that I read Daniel's
reply out of context and too absent-
On Thu, 8 May 2003 15:06:02 +0300, "John Torjo" <[EMAIL PROTECTED]>
wrote:
>Unfortunately, we can't use the do-while(0) idiom, since we don't know when
>while(0) will be ;-)
>
>Example:
>BOOST_ASSERT(i != j)(i)(j);
>
>or
>
>BOOST_ASSERT(i > 1000)(i);
Oops, no. That's not the problem. The problem
>
> That's right. But if this will ever get into boost maybe we'll better
> use the classical do-while(0). Borland warns on if(false), and
> assert(false) is quite common, for instance, in the default case of
> switch statements. BOOST_INVARIANT(false) could be used similarly
> (Though, depending o
On Mon, 5 May 2003 20:12:13 -0700, "Paul Mensonides"
<[EMAIL PROTECTED]> wrote:
>Daniel Frey wrote:
>> Paul Mensonides wrote:
>>
>>> #define BOOST_INVARIANT(expr) \
>>> if (!(expr)) \
>>
>> One possible enhancment:
>>
>>if( expr ); else
>>
>> It prevents problems when the macro is
>From: "David Abrahams" <[EMAIL PROTECTED]>
> "Edward Diener" <[EMAIL PROTECTED]> writes:
>
> >> I browsed the article (I confess to not having read everything, so
> >> please correct any misapprehensions). My sense is that the technique
> >> is oriented towards detecting programmer errors and res
"Edward Diener" <[EMAIL PROTECTED]> writes:
>> I browsed the article (I confess to not having read everything, so
>> please correct any misapprehensions). My sense is that the technique
>> is oriented towards detecting programmer errors and responding via an
>> exception.
>
> I don't think ENFORC
"Andrei Alexandrescu" <[EMAIL PROTECTED]> writes:
>> I browsed the article (I confess to not having read everything, so
>> please correct any misapprehensions). My sense is that the technique
>> is oriented towards detecting programmer errors and responding via an
>> exception.
>
> No.
Please co
David Abrahams wrote:
> "Andrei Alexandrescu" <[EMAIL PROTECTED]> writes:
>
>> By the way, I believe what would be more interesting for Boost is the
>> recent article (http://www.cuj.com/experts/2106/alexandr.htm),
>> written by Petru Marginean and myself. (Warning - the article has
>> recently bee
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Andrei Alexandrescu" <[EMAIL PROTECTED]> writes:
>
> > By the way, I believe what would be more interesting for Boost is the
> > recent article (http://www.cuj.com/experts/2106/alexandr.htm), written
by
> > Petru Margin
11 matches
Mail list logo
