Subject: Re: [boost] [metal] Feature Complete - Request for Feedback
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2017-02-22 18:35:54
On Wed, Feb 22, 2017 at 2:33 AM, Paul Fultz II via Boost <
> > On Feb 21, 2017, at 1:16 PM, Bruno Dutra via Boost <
> boost_at_[hidden]> wrote:
> > Your example is implemented in Metal like this
> > using _ = metal::transform<metal::lambda<std::add_const_t>,
> > metal::as_list<std::shared_ptr<X>>>; // metal::list<X const>
> > metal::apply<metal::lambda<std::shared_ptr>, _> // std::shared_ptr<X
> > Admittedly a bit verbosier, but not too bad.
> > .
> I like this. Its explicit and fast, which I think is good for something
> that is core. From there you could build other frontends that simplify it
> more by deducing the explicit types and then passing them to the core
Exactly. Thanks for your feedback!
> Another thing I saw is that you no longer support gcc 4.8. Why is that? As
> a core library, I would expect good portability, since the portability
> limitations donât just affect Metal but also any libraries that decide to
> use it(or perhaps replace mpl with it).
That is a very good point. I've strived to support the widest variety of
compilers throughout the development of Metal and spent a _lot_ of time,
working around nasty compiler bugs. It is kindda sad, but by now I'm sure I
could ICE either GCC, Clang or MSVC at will. Simply put, at some point I
just gave up on hammering Metal down on older GCC versions.
I just tried to running Metal test suite on GCC 4.9 and it fails the 3rd
test of 200 already. According to the error log, it can't SFINAE away
invalid instantiations of a template that expects N arguments but was given
less than that.
It most probably can be worked around by decltyping a an overloaded
function call, but that kills performance and I'll have to #ifdef it, which
sucks TBH. Nevertheless I'll give it a shot
Ideally, it would be nice if it supported gcc 4.6(even only partially), as
> I would use it in my Tick library and get rid of my homebrew
> metaprogamming. However, I know that might be a lot of work since gcc 4.6
> doesnât have template aliases.
Sadly without alias templates there's not much I could do :(