Boost logo

Boost :

Subject: Re: [boost] About all these metaprogramming libraries
From: Deniz Bahadir (dbahadir_at_[hidden])
Date: 2017-03-20 14:40:45

Am 19.03.2017 um 23:00 schrieb Michael Caisse via Boost:
> On 3/19/17 12:31, Bruno Dutra via Boost wrote:
>> On Sun, Mar 19, 2017 at 7:43 PM, Oswin Krause <
>> Oswin.Krause_at_[hidden]> wrote:
>>> On 2017-03-19 17:13, Bruno Dutra via Boost wrote:
>>>> On Sun, Mar 19, 2017 at 4:22 PM, degski via Boost <boost_at_[hidden]>
>>>> wrote:
> <snip features and criticisms of various libraries>
>> You've pretty much described Metal, except that Metal requires lists to be
>> specializations of metal::list, but that is far from a shortcoming, in fact
>> there is a very good reason behind that design choice.
> <snip more things why-I-designed-my-library-this-way>
> Here is a suggestions. I don't think this thread is the place for the
> authors to explain the benefits of their design/implementation/usage.
> There will be a lot of time for that.
> In this thread, we are trying (as a community) to figure out the best
> approach to deal with multiple submissions of TMP libraries. Lets
> concentrate on that concern.

As mentioned before, I think some kind of comparison between such TMP
libraries is required. A comparison between their features/concepts and
especially the users' needs they try to address with these

For example, from a user's point of view I would pretty much like to see
a "drop-in" replacement for Boost.MPL which compiles (much) faster (and
uses less RAM doing so).
However, I am not really interested in using such a replacement by
myself. I am instead interested in all existing Boost libraries that
currently use Boost.MPL to "magically" become/compile faster (and use
less RAM).

Of course, if all Boost-libraries that use Boost.MPL are actively
maintained and their maintainers would apply internal changes so that
these libraries would use another (faster) TMP library (e.g. Boost.Hana
or what might be adopted next), that would be fine, too.
However, it probably is less work for the maintainer to only adjust some
includes and maybe some typedefs to use a "drop-in" replacement instead
of changing a lot of code to use another TMP library which is completely
different from Boost.MPL.

> Don't worry ... there will be plenty of opportunity for critique and
> defense (o;
> michael

Just my "user's view".


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