Boost logo

Boost :

Subject: Re: [boost] Boost.Conversion: functors namming
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-05-25 05:19:00

On Wed, May 25, 2011 at 10:44 AM, Vicente Botet
<vicente.botet_at_[hidden]> wrote:
> Stewart, Robert wrote:
>> Vicente Botet wrote:
>>> Stewart, Robert wrote:
>>> >    auto f(factory<short>(_1));
>>> >    short const s(f(static_cast<long>(3)));
>>> >
>>> > Your suggestions for the "factory" call are:
>>> >
>>> > A. boost::make_converter_to<short>(_1)
>>> > B. boost::conversion::fp::convert_to<short>(_1)
>>> > C. boost::convert_to<short>(_1)
>>> >
>>> > I definitely dislike B.  A isn't bad, but it should be in the
>>> > boost::conversion namespace.  C is very nice, but it should
>>> > be in the boost::conversion namespace.  The introduction of
>>> > the placeholder is enough to signal that the result is a
>>> > Phoenix lambda.
>>> Even if C is the more elegant, to my taste, it introduce a
>>> dependency on Boost.Phonix even if functors are not used, and
>>> this is one thing I would like to avoid. So it seems that A is
>>> a best compromise.
>> That overload can be put into a separate header so it, and its dependency
>> on Phoenix, is only visible when desired.
>> &lt;boost/conversion/functor.hpp&gt;?
> Hi,
> this independent overloading could be done if there was a class placeholder,
> but in Phoenix a placeholder is a concept, isn't it. So the overloading can
> be done only using SFINAE, which implies that one overload works for T that
> are placeholders and the otherfor T that are no placeholders.
> Let me know if I'm missing something.

FWIW, a phoenix actor is a concept, yes. The file
has only a dependency on the boost/mpl/bool.hpp header. So including this might
not really add to much dependency on your code.

Another possibility certainly is to create your own trait:

template <typename T, typename Enable>
struct enable_functor : mpl::false_ {};

or something, that gets specialized on phoenix::is_actor once your
user includes the
header that enables functors. Using this, you gain another point of
flexibility by being able
to support other functional style libraries.

> Best,
> Vicente
> --
> View this message in context:
> Sent from the Boost - Dev mailing list archive at
> _______________________________________________
> Unsubscribe & other changes:

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