> >>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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
