Guillaume and Giovanni,
  As Beman mentioned, I've been away for a bit. Let's see if I can answer
some of the lingering what-was-the-maintainer-thinking questions:

Giovanni said:
>  Instead, I think this is ill-formed because it's throwing an exception
which
>  is not derived from std::bad_alloc().

This is an error. I'll use std::bad_alloc instead.

Giovanni also said:
>  What is this code supposed to do? If
>  the goal is disabling new() for stateless_integer_add, why simply you
don't
>  add a protected operator new as member of the class?

The goal is for the regression test to fail at run time when operator new ()
is being used. The failure needs to be at run time (not compile time, as the
above solution proposes) because the feature we're testing is an
optimization: compilers that can't do it should still compile the code (it
just has slightly different semantics).

Guillaume said:
>  The best solution would be to track down compilers that complains if the
>  return statement is missing and conditionaly add it for them. But only the
>  maintainer can tell us for which compiler the dummy return statement was
>  needed. Or maybe we could just remove it and see which compilers suddenly
>  complains in the regression tests :-).

Ha! If only the maintainer knew which compiler that was :). If CVS doesn't
tell us, let's just remove the return statement, replace std::runtime_error
with std::bad_alloc, and see who whines about it. I'll commit the patch as
soon as I can, but someone else is welcome to do so if they get there first.

    Doug

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost