Re: [boost] [MPL][vector] Is there interest in mpl::vector using variadic templates?

Subject: Re: [boost] [MPL][vector] Is there interest in mpl::vector using variadic templates?
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2017-02-21 22:03:21

On Tue, Feb 21, 2017 at 11:52 AM, Михаил Максимов via Boost <
boost_at_[hidden]> wrote:

> Dear community,
>
> I've recently started contributing to boost::variant. To speed up variant's
> compilation I'm implementing mpl::vector on variadic templates. For now
> status of new vector implementation is:
>  1) it passes all mpl/test tests on gcc 4.9 and 6.3
>  2) it is decoupled from mpl::vectorN, simultaneously making mpl::vectorN
> visible, so libs like Boost.Geometry, which rely on mpl::vectorN compile
> nicely
>  3) There are several compilation errors during full build on gcc 4.9 and
> 6.3
>  4) I fix problems on mpl/tests stage for clang 3.4 and latest MSVS2017
> compiler
>
> Bruno's introduction of new shiny Metal library and Sergey's comment in the
> same thread:
>
> > The biggest and most useful feature of "new" TMP libraries is variadic
> > templates that increase performance by a really huge factor. The problem
> > with MPL is that vector type sequence must derive from vectorN-s, which
> are
> > documented and can be used in template specialization. So it is
> impossible
> > or pointless to remplement mpl::vector in terms of variadic parameters
> > because of that. The other problem that I can quickly recall is recursive
> > iterator-based approach, which also kills performance.
>
>
> made me wonder, is there interest in variadic templates implementation? Are
> there limitations for it's usefulness, which I did not see?

I'll give you my opinio as someone who has contributed bugfixes to MPL in
the past, fiddled with the idea of modernizing it and eventually end up
with a "new shiny Metal" (I appreciate the compliment).

By now you have certainly realized that under the hood MPL is a very
complex piece of software full of quirks and tricks that magically fit
together to provide a clean and very well designed interface to the user.
Half of those were workarounds for broken compilers that probably aren't
used by anyone for a decade now, the other half consisting in the emulation
of language features made obsolete by C++11. If you take these out, not
much is left but tag dispatching and the public API. In an attempt to
modernize MPL, it would probably be much easier to rewrite it from scratch,
but then why not taking full advantage of modern features and adapting the
public API accordingly, while at the same time fine tuning for performance
and ease of use?

My two cents.

Regards,
Bruno