Boost logo

Boost :

Subject: Re: [boost] [Hana] Informal review request
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-03-05 19:39:40

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. 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.


ned Productions Limited Consulting

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