Boost logo

Boost :

Subject: Re: [boost] [mpl] multiset
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2015-02-24 18:06:27


2015-02-24 18:46 GMT-03:00 Vicente J. Botet Escriba <
vicente.botet_at_[hidden]>:

> Either I expressed myself incorrectly or you miss-understood me. When I
> said easier I was thinking on a new library compared to a library that has
> to preserve MPL compatibility.
>
> BTW, I like a lot your library. However I don't think it would be easy to
> introduce its design on the C++ standard library. IMHO pure
> meta-programming additions should be easier to introduce. Of course, I can
> be wrong.
>
>
Do you see anything so broken within MPL's design that justifies dropping
backwards compatibility and redesign a new library from scratch? Is it
really necessary, considering the existence of other modern options which
already focus on an strict C++14 approach, such as Hana?

IMO the fact it mimics the standard library is very positive, for it makes
transition much easier for someone used to the STL first experimenting with
metaprogramming. It sure is not the best design for an essentially
functional library, but I don't see why it could not provide various
interfaces, one of them being iterators, i.e. preserving its current
interface.

Taking a closer look at the code, the bulk of it really is just dealing
with broken compilers. On one hand I totally agree that getting rid of
(some of) them would simplify things a lot, counting on the fact that
anyone that can put up with such an outdated compiler as MSVC 6 could as
well tolerate using a not so outdated version of boost. On the other hand,
I think this is one of the greatest achievements of MPL and I would resist
the idea at first, until it proves really necessary.

In any case, I fail to see a very good reason for deprecating MPL in favor
of a completely new design, assuming the desire to also maintain a pure
metaprogramming library that is.

*Bruno C. O. Dutra*


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