Re: [boost] Re: smart assert (was: ENFORCE/ better assertiontechnique)

From: John Torjo (john_at_[hidden])
Date: 2003-05-08 06:47:35

> >>BOOST_ASSERT(some_lenghty_function())(???)
> >
> > 2. BOOST_ASSERT( some_lengthy_function() > 10)
 some_lengthy_function());
> > Indeed, is kind of lengthy, but this is life :-(
> > The point is that I could provide the v_ macro as well - it would not be
too
> > complicated. What do others think?
>
> I wondered about this as well. Here is one option:
>    BOOST_PREPARE_ASSERT(int _result=some_lengthy_function());
>    BOOST_ASSERT(_result>10)(_result);
>
> I've used something like this in my own assert library, but have never
been
> happy with having a local variable that is only there in debug mode.
>
> How would the v_ macro work?

the PREPARE is an interesting idea.
About the v_ macro, was something very simple, like
#define v_(x) (do_some_print(x, #x))

It should work like this:

BOOST_ASSERT( v_(some_lengthy_function()) > 0);

instead of

BOOST_ASSERT( some_lengthy_function() > 0)( some_lengthy_function() );

I guess it could be implemented like this:
----------------
#include <iostream>

struct Keeper
{
    Keeper(int) {}
    operator bool() { return false; }

    template< class type>
        void log( const type & val, const char * str)
    { std::clog << str << "=" << val; }
};

template< class type>
struct log_me_t
{
    log_me_t( const value & val, const char * str, Keeper & k)
        : m_val( val)
    { k.log( val, str); }

    const type & m_val;
};

template< class type> log_me_t< type> log_me( const type & val, const char *
str, Keeper & k)
{ return log_me_t< type>( val, str, k); }

#define BOOST_ASSERT(expr)
    if ( Keeper k=0 ) ; \
    else if ( (expr) ) ; \
    else \
        <like before> \

#define v_(x) log_me(x, #x, k).ref

----------------
This will allow for the v_ macro.
What do you think?

>
> >>If not-idempotent function is given as parameter, it may have
sideeffects
> >>(silly contrived example: pool resource allocator which gets exhausted
in
> >>the middle of assert).
> >
> > I did think (a lot!) about this. But, it's reasonable to assume that
> > functions/ member functions that are called within an ASSERT should all
be
> > constant, because they won't be called at all in release mode.
>
> I'm not convinced that is reasonable, but even if no side effects the
assert
> might take a significant amount of time (e.g. checking an object matches
> what is in a back-end database, or checking a graph has no cycles).

True. So probably adding the v_ macro is a very good idea.

Best,
John