Could you please expand on the nature of metaprogramming you have been doing with constexpr? Are you talking about manipulating values of a literal type, or about "pure type" computations?
It has been mostly about manipulating values of a literal type and tuples.
I'm still new to these kind of situations but I can see myself in the
future preferring to use a std::tuple as a type vector (ignoring the
values) and performing transformations inside a constexpr function using a
Boost.Fusion-like library and then just decltype the result to get the
type. Relaxed constexpr and automatic type deduction for normal functions
makes this approach straightforward.
To get the point across, this is how the machinery and the usage _could_
look like:
/// Quote:
template
struct quote { template<class T> auto operator()(T&&) { return U<T>{}; }
};
/// Your complex transform function:
template<class Tuple> constexpr auto my_transform(Tuple&&) {
// note: Fusion is not annotated with constexpr yet
auto tmp = boost::fusion::transform(Tuple{}, quotestd::add_pointer_t{});
return boost::fusion::transform(tmp, quotestd::add_reference_t{});
}
/// Usage:
using ref_to_pointers = decltype(my_transform(std::tuple
"What is the purpose of a TMP library?"
This is a very good question. Is the compile-time reflection offered by Boost.Fusion metaprogramming? If so, Boost.MPL and Boost.Fusion would have some overlap that might be worth studying.
I hope this answers your questions; sorry for the long-winded answer but I think it can be informative for others too.
Thanks for the answer, you are doing a great job!
Bests,
Gonzalo
On Tue, Apr 29, 2014 at 11:42 PM, Louis Dionne
Roland Bock
writes: I agree completely. I recently developed my own type set since I could not use MPL (no full variadicity) or the standard library (no type set). And even though it was kind of fun to implement, I would have preferred to use something from the standard (or from something aiming to become the standard).
By any chance, would the type set implementation happen to be public? I know of a couple different ways to implement those, but it's always good to see what others have done.
That being said, I think you should aim for TMP14. Personally I would very much consider C++14 plus Concepts Lite, because you are building a library for the future, not for the past.
As I currently view things, C++14 won't be such a game changer wrt TMP, but I must look into Concepts Lite more seriously before that's definitive. See my answer to Gonzalo for more on that.
TYVM for your input, Louis
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Dipl.-Ing. Gonzalo Brito Gadeschi Institute of Aerodynamics and Chair of Fluid Mechanics RWTH Aachen University Wuellnerstraße 5a D-52062 Aachen Germany Phone: ++49-(0)241-80-94821 Fax: ++49-(0)241-80-92257 E-mail: g.brito@aia.rwth-aachen.de Internet: www.aia.rwth-aachen.de