On Wed, 2017-02-22 at 19:35 +0100, Bruno Dutra wrote:
On Wed, Feb 22, 2017 at 2:33 AM, Paul Fultz II via Boost <boost@lists .boost.org> wrote:
On Feb 21, 2017, at 1:16 PM, Bruno Dutra via Boost <boost@lists.b oost.org> 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 const>
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 components.
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
Exactly. Thanks for your feedback! 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 https://github.com/brunocodutra/metal/issues/59
I think picking a slower implementation on older compilers is acceptable. This way I can develop with newer compilers which are fast, and deploy with the older compilers. Also, having a faster compilation with newer compilers is a good way to convince management to move to a newer compiler.
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 :(
Well on gcc 4.6 inheritance can be used instead of an alias, but then you would need an evaluation step, like: METAL_EVAL(metal::drop<l3, metal::number<3>>) And then the library would need to apply these evaluations internally as well. I don't know know if you would accept a PR with changes to support gcc 4.6 or not. Of course the first thing is to support for gcc 4.8 and then we could move backwards toward 4.7 and then 4.6. Paul