Imagine if you could pass a code block (i.e. { to } ) as a template argument
... and then expand it inline using a special operator, say # for the sake
of argument. Then you could things like this:

template<bool b, typename T1, typename T2> ConcatenateBlock() {
    #T1
    #T2
};

void FuBar() {
    #ConcatenateBlock
    <
       {cout << "fu"; << endl; },
       {cout << "bar"; << endl; }
    >
}

But that is only the tip of the iceberg. It would allow for much more
sophisticated metaprogramming than is currently possible. How much value can
people see in allowing such a construct for C++?

On a related note, If anyone is interested, I have built this capacity into
Heron and I explain it in depth at
http://www.heron-language.com/metaprogramming.html

--
Christopher Diggins

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

cdiggins@videotron.ca ("christopher diggins") writes:

> Imagine if you could pass a code block (i.e. { to } ) as a template argument
> ... and then expand it inline using a special operator, say # for the sake
> of argument. Then you could things like this:
>
> template<bool b, typename T1, typename T2> ConcatenateBlock() {
>     #T1
>     #T2
> };
>
> void FuBar() {
>     #ConcatenateBlock
>     <
>        {cout << "fu"; << endl; },
>        {cout << "bar"; << endl; }
>     >
> }

You can already pass function pointers/references as template
parameters.  If those functions are inline they can be expanded
inline.  All we'd need is true lambdas and we'd be able to do
everything you're doing above.

> But that is only the tip of the iceberg. It would allow for much more
> sophisticated metaprogramming than is currently possible. How much value can
> people see in allowing such a construct for C++?

> On a related note, If anyone is interested, I have built this capacity into
> Heron and I explain it in depth at
> http://www.heron-language.com/metaprogramming.html

That's just a fancy way of saying "macro" as far as I can tell ;-).
The block is preserved as raw text and only parsed in the context of
the function where it is generated, right?

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi Dave,

"David Abrahams" <dave@boost-consulting.com> wrote in message
news:uvfe5kgab.fsf@boost-consulting.com...
> cdiggins@videotron.ca ("christopher diggins") writes:
>
> > Imagine if you could pass a code block (i.e. { to } ) as a template
argument
> > ... and then expand it inline using a special operator, say # for the
sake
> > of argument. Then you could things like this:
> >
> > template<bool b, typename T1, typename T2> ConcatenateBlock() {
> >     #T1
> >     #T2
> > };
> >
> > void FuBar() {
> >     #ConcatenateBlock
> >     <
> >        {cout << "fu"; << endl; },
> >        {cout << "bar"; << endl; }
> >     >
> > }
>
> You can already pass function pointers/references as template
> parameters.  If those functions are inline they can be expanded
> inline.  All we'd need is true lambdas and we'd be able to do
> everything you're doing above.

A hypothetical true lambda would undoubtably be beneficial. The code-block
propopsal would have access to variables local to the scope of where the
expansion occurs (like a macro).

> > But that is only the tip of the iceberg. It would allow for much more
> > sophisticated metaprogramming than is currently possible. How much value
can
> > people see in allowing such a construct for C++?
>
> > On a related note, If anyone is interested, I have built this capacity
into
> > Heron and I explain it in depth at
> > http://www.heron-language.com/metaprogramming.html
>
> That's just a fancy way of saying "macro" as far as I can tell ;-).

A macro is just text whereas a code-block is guaranteed to be a set of well
formed statements contained within matching curly braces. Macros can not be
passed as a template parameter.

> The block is preserved as raw text and only parsed in the context of
> the function where it is generated, right?

Yes. But when a code-block is declared as a meta-function, the parameters
are guaranteed to be types as opposed to just primitive token replacement
like a macro. This allows us to completely avoid the macro token replacement
error problems. In the end Heron metaprogramming replaces the need for
macros by more fully leveraging the type system. This is what could be done
in C++ if you allowed blocks to be treated like types.

--
Christopher Diggins
http://www.heron-language.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]