Boost logo

Boost :

Subject: Re: [boost] [GSoC][MPL11] Post C++Now update
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2014-05-19 14:50:30


On 19/05/2014 02:28 p.m., Louis Dionne wrote:
> Joel de Guzman <djowel <at> gmail.com> writes:
>
>>
>> On 5/19/14, 4:41 AM, Louis Dionne wrote:
>>> After discussing the issue several times during the week, I (and others)
>>> think it might be possible to merge Fusion and the MPL into a single
>>> library. I am currently trying to write a library that does that. Since
>>> this constitutes a large reorientation, I created a new repository which
>>> is available at [2]. Those with interest should consider subscribing to
>>> the repository to be updated as I make progress.
>>
>> Been there tried that...
>>
>> This has been proposed several times in the past. I reiterate my
>> position: MPL and Fusion are different beasts and it is not good for
>> both to be merged (if it is at all possible). MPL does not have the
>> runtime components that Fusion needs and Fusion has runtime
>> components that MPL *does not* need.
>
> This is true, the MPL does not _need_ a runtime component. Adding one should
> be harmless if done correctly. There might be a performance penalty though,
> but I'll benchmark that eventually.
>

Having done my own research on what a C++11/14 aware Fusion library
would be, I concur with Louis. The optimal implementation for sequences
and (most) algorithms look the same for MPL and Fusion, where the MPL
implementation is built by wrapping and unwrapping arguments around
Fusion calls. Additionally, while I wouldn't go as far as to say that
iterators are a design flaw, they do get in the way of reducing
compilation time while offering no real advantage (iterators are a
compile-time thing in both libraries after all).

I would like to encourage Louis to experiment with this approach, as
long as it doesn't compromise the goal of optimal compilation times for MPL.

Regards,

-- 
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk