On 19/05/2014 02:28 p.m., Louis Dionne wrote:
Joel de Guzman
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