Re: [boost] [GSoC, MPL11] Community probe

Subject: Re: [boost] [GSoC, MPL11] Community probe
From: Gonzalo Brito Gadeschi (g.brito_at_[hidden])
Date: 2014-04-30 04:19:45

>
> 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<template <class> class U>
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{}, quote<std::add_pointer_t>{});
  return boost::fusion::transform(tmp, quote<std::add_reference_t>{});
}

/// Usage:
using ref_to_pointers = decltype(my_transform(std::tuple<int, char, void,
my_own_type>{}));

This approach has advantages/disadvantages, the ones that come to mind are:
- i think it only works if the types in the tuple have constexpr
constructors (_huge drawback_ unless a workaround is found),
- performance (it might be slower to compile, but I haven't profiled so I
don't know),
- it gives you a unified way of performing type-only and type-value
manipulations at compile-time,
- it might be easier to explain to beginners since it is more imperative
and has less templates,
- you cannot use lambda functions inside relaxed-constexpr functions (so
the restricted part of C++ that is allowed inside constexpr functions needs
to be considered).

I'm not proposing this as a good way to do metaprogramming. I've just found
that this way is useful in some situations and I think it is worth
exploring to get a better idea of its advantages/disadvantages.

 >"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 <ldionne.2_at_[hidden]> wrote:

> Roland Bock <rbock <at> eudoxos.de> 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_at_[hidden]
Internet: www.aia.rwth-aachen.de