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.