On Tue, Feb 21, 2017 at 11:52 AM, Михаил Максимов via Boost < boost@lists.boost.org> 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