Boost logo

Boost :

Subject: Re: [boost] [Hana] Informal review request
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2015-03-05 20:11:39

Niall Douglas <s_sourceforge <at>> writes:

> On 5 Mar 2015 at 19:02, Louis Dionne wrote:
> > > - // BOOST_HANA_RUNTIME_CHECK is equivalent to assert
> > > In that case, what is the point of using it instead of assert?
> > > I think you should probably avoid using these constructs
> > > in the user documentation of other parts of the library.
> > > It's just a distraction, so it's better to rely on
> > > standard components, which users probably already
> > > understand.
> >
> > The problem is that `assert` is not define when NDEBUG is defined,
> > but I want my tests to fire up all the time. Since these examples
> > are Doxygen'd out of actual source files, the macros end up in the
> > documentation. Basically, If I could redefine `assert` to be
> > `BOOST_HANA_RUNTIME_CHECK` in those test files, I'd be really
> > happy. Would it be against good software craftsmanship to write
> >
> > ... include all you need ...
> >
> > #ifndef assert
> > # define assert(...) BOOST_HANA_RUNTIME_CHECK(__VA_ARGS__)
> > #endif
> I'd suggest an alternative course: these are "current state is
> impossible" assertions right? In which case fatal application exit is
> the only valid outcome, plus you want them always there even in
> optimised builds, and ideally you want some sort of useful error
> message.

The *_CHECK macros in Hana are just meant to be used for unit
testing. They should be enabled in all build configurations so
I can test both the Debug and Release modes. Currently,
BOOST_HANA_RUNTIME_CHECK(expr) is defined (roughly) as
    if (!expr) {
        std::cerr << "some useful error message";

Of course it is less naive PP-wise, but that's the gist of it.

> You may find my BOOST_AFIO_THROW_FATAL(x) macro of use here
> io/detail/Utility.hpp#L135. It tries to throw an exception in a
> noexcept function first, and if that succeeds (e.g. MSVC) then it
> calls std::terminate.
> The print_fatal_exception_to_stderr() function dumps a stack trace to
> stderr on supported platforms, just to be very, very sure you get
> something debuggable. Most of AFIO's testing happens on a Jenkins CI
> to catch the really rare non-repeatable bugs, the ones not findable
> on your dev workstation, so having useful telemetry as to what went
> wrong is invaluable.

Thanks, I was wishing for a stack trace just earlier today.
I'll take a look.


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