Andrey Semashev wrote:
Yes, I had similar idea. I'll try to extract minimal bits of MPL in a
separate branch in Core, maybe dropping some workarounds in the process to
reduce the amount of code.
Extracting the commonly used parts of MPL such as mpl::bool_, mpl::if_,
mpl::and_ will help, although I'd argue that they need to go into module
mpl_core, not into module core.
But this will not solve the problem that using boost::is_pod adds MPL to the
dependency graph. It will only let us specialize it without depending on
MPL.
On Tue, Jun 3, 2014 at 11:49 AM, John Maddock
wrote:
Right, what's wrong with: [...]
This is mpl::bool_:
// bool_fwd.hpp:
#include
BOOST_MPL_AUX_ADL_BARRIER_NAMESPACE_OPEN
template< bool C_ > struct bool_;
// shorcuts
typedef bool_<true> true_;
typedef bool_<false> false_;
BOOST_MPL_AUX_ADL_BARRIER_NAMESPACE_CLOSE
BOOST_MPL_AUX_ADL_BARRIER_DECL(bool_)
BOOST_MPL_AUX_ADL_BARRIER_DECL(true_)
BOOST_MPL_AUX_ADL_BARRIER_DECL(false_)
// bool.hpp:
BOOST_MPL_AUX_ADL_BARRIER_NAMESPACE_OPEN
template< bool C_ > struct bool_
{
BOOST_STATIC_CONSTANT(bool, value = C_);
typedef integral_c_tag tag;
typedef bool_ type;
typedef bool value_type;
operator bool() const { return this->value; }
};
#if !defined(BOOST_NO_INCLASS_MEMBER_INITIALIZATION)
template< bool C_ >
bool const bool_::value;
#endif
BOOST_MPL_AUX_ADL_BARRIER_NAMESPACE_CLOSE
So, at minimum, we need integral_c_tag. I'm not sure about the ADL barriers.
Here's the tag:
#include
#include
BOOST_MPL_AUX_ADL_BARRIER_NAMESPACE_OPEN
struct integral_c_tag { BOOST_STATIC_CONSTANT(int, value = 0); };
BOOST_MPL_AUX_ADL_BARRIER_NAMESPACE_CLOSE
BOOST_MPL_AUX_ADL_BARRIER_DECL(integral_c_tag)
So it looks tractable in principle, but putting those things into core is,
to use your characterization, abhorrent.
