Boost logo

Boost :

From: Daniel James (daniel_at_[hidden])
Date: 2005-12-22 16:17:36

Gennadiy Rozental wrote:

> I guess it could be a matter of preference. I could try to support
> alternative that throw user supplied exception. There are several
> complications:
> 1. Macro does not support varargs. That mean We need add new macro into
> interface
> 2. Currently all methods are virtual. I couldn't pass custom user exception
> throw non-template virtual call.

Would it be possible to supply a templated exception that could be used.
Something like:

     struct hash_exception_tag {};
     typedef boost::itest::exception<hash_tag> hash_exception;

     // An exception derived from hash_exception
     struct hash_constructor_exception_tag {};
     typedef boost::itest::exception<hash_constructor_tag,
         hash_exception> hash_constructor_exception;

Would that be easier?

Although, I get the impression that making use of your scope tracking
might be easier.

>>Some of the other exception
>>specifications details which methods exceptions can be thrown from, so
>>you need quite fine-grained control.
> Sorry I did not get this statement.

I was referring to something like:

   "For unordered associative containers, no swap function throws an
exception unless that exception is thrown by the copy constructor or
copy assignment operator of the container’s Hash or Pred object (if any)."

Which is from TR1 To be honest, this one is pretty easy to
deal with, but I could imagine more difficult ones.

> P.S. Other then issues we discussing now, what is you general impression of
> new facilities?

Sorry, I always concentrate on the negative.

It looks very powerful. It does a lot more than my test framework does
and is better designed (my tests were thrown together as I went along).
And it found a bug in one of my tests - I was using std::rand() but
forgot to reset the seed at the beginning of each iteration, and your
framework noticed that it was acting inconsistently. It will be
interesting to see how this works in practice.

I think most of my problems came from trying to migrate my tests from my
framework to yours. And the specification for unordered associative
containers is fairly demanding, although with the increasing popularity
of policy templates that could become more common.

I'll continue with it and let you know how I get on.

I forgot to answer this before:

> I realize that global operator new overload bound to cause some false
> positives under some circumstances. Users will need to address this in their
> code. If you have any better proposition I am all for it.

boost::itest::exception_safety could take an extra parameter which takes
flags to turn of parts of the testing tracking (although that depends on
how easy it is to seperate them). Maybe something like:

     boost::itest::exception_safety(&insert_test, "Insert Test",

I don't think there's any need to make this accessible through the macro.


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