Boost logo

Boost :

Subject: Re: [boost] Call for interest - BOOST_AUTO_FUNCTION
From: David Abrahams (dave_at_[hidden])
Date: 2010-10-18 11:14:35


At Mon, 18 Oct 2010 22:17:25 +0800,
Dean Michael Berris wrote:
>
> On Mon, Oct 18, 2010 at 9:55 PM, David Abrahams <dave_at_[hidden]> wrote:
> > At Mon, 18 Oct 2010 18:45:24 +0800,
> > Dean Michael Berris wrote:
> >>
> >> Now say the standard doesn't get changed to support what you're
> >> proposing (I really hope you'll write the N**** paper so that the C++
> >> committee members can address your concern and the (now in hindsight)
> >> obvious mistake), the use case you intend to enable deserves enough
> >> attention.
> >
> > FWIW, I seriously doubt this result is from lack of attention.  Much
> > more likely it's due to "implementability concerns."  Understanding
> > that could be important to writing a convincing paper.
> >
>
> Does it help the argument for a change if a macro can do the job?

Maybe; I don't know.

> I mean, what can a preprocessor macro do that the compiler can't
> built-in from the front-end? :D

“Look ahead” without processing the code semantically.
“Implementability” is not a question of whether it can be implemented
at all, but of whether it can be implemented reasonably within the
architecture of existing compilers. If it requires a ground-up
redesign of some major compiler, it's effectively unimplementable.

> I also doubt the committee members weren't paying attention. The
> standard is already huge as it is and diving deep into the details
> (and the aesthetics) of the implementation of one specific feature is
> time and effort consuming.
>
> I really hope it's not yet beyond repair at this point. :)

I wouldn't hold out much hope that this can happen for C++0x, unless
you can convince some national body that it's so important that the
standard should be rejected if they don't get it. That's what
happened for exception-safety. But that sort of thing is rare.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

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