Re: [boost] [utility] Proposal to extract some components from Boost.Log

Subject: Re: [boost] [utility] Proposal to extract some components from Boost.Log
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-09-01 04:40:25

On Sunday 01 September 2013 03:27:06 Daryle Walker wrote:
> > Date: Wed, 28 Aug 2013 12:14:51 +0400
> > From: andrey.semashev_at_[hidden]
> > 
> > 1. BOOST_EXPLICIT_OPERATOR_BOOL() macro for defining explicit operator
> > bool() for a class.
> 
> I could add this to my touch-ups of Boost.Rational, but I see two minor
> problems using it:
> 
> a. It isn't marked "constexpr."  I can add that myself before using
> "BOOST_EXPLICIT_OPERATOR_BOOL" in "boost/rational.hpp," but what happens if
> someone corrects it in "explicit_operator_bool.hpp"?  Will the (temporary)
> double definition cause an error?

Well, since there isn't a constexpr_if or something, I don't see a way to add 
it to BOOST_EXPLICIT_OPERATOR_BOOL. I could add 
BOOST_EXPLICIT_OPERATOR_BOOL_PP(pre, post), which would add pre() and post() 
before and after the operator signature. For example:

  BOOST_EXPLICIT_OPERATOR_BOOL_PP(\
    BOOST_PP_IDENTITY(BOOST_CONSTEXPR), BOOST_PP_EMPTY())

would expand to something like

  constexpr explicit operator bool() /* nothing */ { ... }

Although I'm not sure the expansion will be correct if BOOST_CONSTEXPR expands 
to nothing. PP gurus?

A simpler alternative would be just BOOST_CONSTEXPR_EXPLICIT_OPERATOR_BOOL 
macro.

> b. Its #included Boost.Log-specific configuration header file flags an error
> if RTTI isn't active.  And it's unconditional, which would make
> Boost.Rational unusable for small environments that skip RTTI.  But I don't
> know if Boost.Rational is already unsuitable for such systems, since it
> uses exceptions and such.

It won't include these headers after extraction and it won't require RTTI.