Boost logo

Boost :

Subject: Re: [boost] [c++11]
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2013-06-18 14:46:35


On Tue, Jun 18, 2013 at 6:41 PM, Niall Douglas <ndouglas_at_[hidden]>wrote:

> > > Now, nothing in proposed Boost.AFIO uses variadic templates in a way
> > > not replaceable with preprocessor programming. However it very
> > > /nearly/ did: I had this neato bit of evil variadic instantiation
> > > which let you convert an unknown set of trailing args into a
> > > std::tuple<> for storage, then /unpack/ said std::tuple<> back into an
> > > unknown set of trailing args, all with perfect forwarding. Effectively
> > > it was a compile-time std::function<> implementation.
> > >
> > [snip]
> > I can already here you ranting about how variadic templates allows you to
> > use
> > an arbitrary number of parameters while the preprocessor solution can
> not.
>
> "Ranting"? That's a little harsh don't you think? I am plenty aware that
> variadic templates have similar limits in parameter depth as recursive
> templates.
>

Sorry, I didn't mean to offend you. English isn't my native language and i
sometimes use inappropriate words when I am excited about something :P

>
> Actually that wasn't the problem I found. And yes, I am more than well
> aware
> of Boost's existing facilities in Phoenix et al. and thanks to everyone for
> pointing them out in depth.
>
> > > That evil variadic template machinery gets rid of that problem. And
> > > its only replacement is std::function<> - you *cannot* implement that
> > > functionality (pure compile time std::function<>) without variadic
> > > templates because you can't properly unpack them without.
>
> I'll quickly explain the problem I found just for the list's reference: I
> struggled to implement nested args-to-tuple => tuple-to-args expansion
> without
> variadic templates i.e. if I bind up a callable and a set of args into a
> compile time container, and then pass that itself as part of a set of
> unknown
> args, I kept running into instantiation limits in C++03 era compilers.
>
> I'll entirely grant you, before anyone comments, that it could be entirely
> my
> own shoddy metaprogramming skills. And yes, I know you can tell some
> compilers
> to increase their hard limits.
>
> Either way, with C++03 era compilers it just became easier to use a
> function<>, push the problem into the runtime and be done with it,
> especially
> as the preprocessor generated template specialisations are lengthy and
> substantially extend compile times, as other posts have mentioned.
>
> That was the basis of my "quite bold statement" which you don't think
> holds:
> an earlier failure of mine in C++03 which was fairly straightforward to
> implement in C++11, and something I probably would have moved ahead with in
> Boost.AFIO if it weren't that I'm pretty sure we'll need to drop the
> variadic
> templates requirement. I accept, given the list's response, that the cause
> is
> likely my incompetence as a programmer and others on this list can perform
> magic I cannot. I therefore retract my earlier assertion.
>

You shouldn't resort to so much humbleness. I think, as a takeaway from
this discussion we should appreciate that variadic templates are indeed
superior to a preprocessor based solution (at least from the codeability
aspect). Furthermore i believe that pushing that feature is also a good
idea. However, that has many implications and everyone involved needs to be
aware of those. I will support you in your efforts for going for a C++11
based solution under the condition that boost will move on and deprecate
all libraries that will be unusable with a C++03 compiler. Maybe Boost.AFIO
should be the library that advocates and pushes this breaking change.

>
> Niall
>
> ---
> Opinions expressed here are my own and do not necessarily represent those
> of
> BlackBerry Inc.
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk