Is template metaprogramming allowed by the standard?

[Peter]

It's going to be a very general question, but here it goes: is template metaprogramming a serious programming technique, used in real-life code? Is there anything in C++ standard that guarantees its validity and/or portability (at least to some extent) or is template metaprogramming merely a curiosity, an unexpected side effect of adding templates to language definition and everything about it is either undefined or implementation defined?

[Robert Wessel]

On Fri, 10 Apr 2015 15:22:18 -0700 (PDT), Peter
<pil...@poczta.onet.pl> wrote:

>It's going to be a very general question, but here it goes: is template metaprogramming a serious programming technique, used in real-life code? Is there anything in C++ standard that guarantees its validity and/or portability (at least to some extent) or is template metaprogramming merely a curiosity, an unexpected side effect of adding templates to language definition and everything about it is either undefined or implementation defined?

There's no real boundary between using templates as the sort-of
soupped up macro facility it was intended for, and for
meta-programming. It's just that templates are a crappy programming
language (as a direct result as not having be designed for that
purpose). But the techniques used are not new or uncommon. More than
a bit of CS involves doing things with recursion instead of iteration,
for example, and that, plus a bit of string hackery, gets you to doing
the same with templates.

[Jorgen Grahn]

Well, /The C++ Programming Language/ dedicates chapter 28 to TMP ...

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Öö Tiib]

On Saturday, 11 April 2015 01:22:32 UTC+3, Peter wrote:
> It's going to be a very general question, but here it goes: is template
> metaprogramming a serious programming technique, used in real-life code?

Yes. Every trick (including preprocessor or template metaprogramming)
for to achieve that something is done compile-time or before it
rather than run-time is actually used in real programs written in C++.

> Is there anything in C++ standard that guarantees its validity
> and/or portability (at least to some extent) or is template
> metaprogramming merely a curiosity, an unexpected side effect of
> adding templates to language definition and everything about it is
> either undefined or implementation defined?

Why you ask several, orthogonal to each other questions in same
sentence?
a) Turing-complete set of template metaprogramming techniques is
guaranteed by C++ standard.
b) These techniques are non-portable only to where the compilers
are non-conformant.
c) It is curiosity.
d) It was unexpected side effect of adding templates to language.
e) Some people will always use (either by accident or knowingly)
some undefined or implementation defined effects regardless if
those are related to templates or not.

Important questions you did not ask:

Is metaprogramming in general needed for writing better programs?
No. We can do metaprogramming in our heads. Often we can also let
programs to do things run-time without big disadvantage. It may be
performs slightly worse and gives defect reports bit later.

Is the template metaprogramming needed for writing better programs?
It is not. We can ourselves always use other, nicer means of code
generation.

Is the C++ template metaprogramming needed for writing better
C++ libraries?
Sometimes. Flexibility in integration layer may give wider
usability. Early diagnostics are good so user does not waste his
time to trying to misuse the library and what little is
performance-critical for user may differ per user. The C++
preprocessor metaprogramming is even worse and delivering
separate tools with library adds to complexity of its usage.

[Juha Nieminen]

Peter <pil...@poczta.onet.pl> wrote:
> It's going to be a very general question, but here it goes: is template metaprogramming a serious programming technique, used in real-life code? Is there anything in C++ standard that guarantees its validity and/or portability (at least to some extent) or is template metaprogramming merely a curiosity, an unexpected side effect of adding templates to language definition and everything about it is either undefined or implementation defined?

Btw, define "template metaprogramming".

Would you consider the following "template metaprogramming", or would
you consider it something else?

Consider what happens here:

std::vector<size_t> v(10, 20);

You are constructing a vector with 10 elements, each having the value 20.
But how does the compiler know you are wanting to do that? The question
raises because std::vector has a constructor taking two iterators, which
is declared effectively as:

template<typename Iter>
std::vector<ValueType>::vector(Iter begin, Iter end);

That vector creation earlier matches that declaration perfectly. Yet still,
somehow, the compiler doesn't try to call this, and instead calls the
correct constructor (ie. the one that takes a number and a value to
initialize the vector with).

std::vector achieves this via template trickery. Would you consider
this "template metaprogramming"? It certainly is non-trivial trickery
using templates.

--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---

[Jorgen Grahn]

On Sat, 2015-04-11, Juha Nieminen wrote:
> Peter <pil...@poczta.onet.pl> wrote:

>> It's going to be a very general question, but here it goes: is
>> template metaprogramming a serious programming technique, used in

...

>
> Btw, define "template metaprogramming".
>
> Would you consider the following "template metaprogramming", or would
> you consider it something else?
>
> Consider what happens here:
>
> std::vector<size_t> v(10, 20);
>
> You are constructing a vector with 10 elements, each having the value 20.
> But how does the compiler know you are wanting to do that? The question
> raises because std::vector has a constructor taking two iterators, which
> is declared effectively as:
>
> template<typename Iter>
> std::vector<ValueType>::vector(Iter begin, Iter end);
>
> That vector creation earlier matches that declaration perfectly. Yet still,
> somehow, the compiler doesn't try to call this, and instead calls the
> correct constructor (ie. the one that takes a number and a value to
> initialize the vector with).
>
> std::vector achieves this via template trickery. Would you consider
> this "template metaprogramming"? It certainly is non-trivial trickery
> using templates.

"Trickery" implies, as I understand the word, something devious and
undocumented that you're not supposed to learn about. Isn't this just
the usual overloading rules, extended to include templates? Out of
the two constructors

vector(size_type n, const T& t)

template <class InputIterator>
vector(InputIterator, InputIterator)

the former is a decent match, and the latter is worse (and wouldn't
compile anyway if it was chosen).

[Paavo Helde]

Jorgen Grahn <grahn...@snipabacken.se> wrote in
news:slrnmiipf6.2...@frailea.sa.invalid:

10 and 20 are of type int, which is different from size_type and const
size_t&. A little experiment shows this is not so trivial:

#include<iostream>

template<class T>
class myvector {
public:
myvector(size_t n, const T& value) {
std::cout << "A\n";
}
template<typename ITER>
myvector(ITER a, ITER b) {
std::cout << "B\n";
}
};

int main() {
myvector<size_t> x(10, 20);
return 0;
}

This prints "B" with my compiler. When 10 and 20 are cast to size_t, it
prints "A" indeed, but requiring such exact types would make using
std::vector much more cumbersome.

As far as I understand, the "template trickery" is needed for getting the
second constructor to fail at the substitution stage (SFINAE) for integer
types so that the first constructor gets selected. And yes, switching
overloads on and off at compile time seems pretty TMP for me.

Cheers
Paavo

[David Harmon]

On Sat, 11 Apr 2015 18:05:41 +0000 (UTC) in comp.lang.c++, Juha Nieminen
<nos...@thanks.invalid> wrote,

>Btw, define "template metaprogramming".

Writing your own c++ templates, as distinguished from using templates
someone else has written or from the standard library.

[Jorgen Grahn]

It's not worse, of course -- it's a perfect match, with
InputIterator = int. Sorry for confusing things.

>> (and wouldn't compile anyway if it was chosen).
>
> 10 and 20 are of type int, which is different from size_type and const
> size_t&. A little experiment shows this is not so trivial:

[snip]

> As far as I understand, the "template trickery" is needed for getting the
> second constructor to fail at the substitution stage (SFINAE) for integer
> types so that the first constructor gets selected. And yes, switching
> overloads on and off at compile time seems pretty TMP for me.

Whatever it is, I now see it's worth understanding.

[Paavo Helde]

David Harmon <sou...@netcom.com> wrote in news:D8idnXi_a7LFn7fInZ2dnUU7-
Iud...@earthlink.com:

This might be a useful definition, but not exactly what the OP was
interested in. He asked: "Is template metaprogramming a serious
programming technique, used in real-life code?" and "Is template
metaprogramming allowed by the standard?"

These are actually a bit orthogonal questions, but answer to both is yes.
The standard library and many other template libraries (including many
Boost libraries, for example) are pretty serious and used very heavily in
real world. And yes, this is all backed up by the standard.

As always, any given C++ compilers might lack or misbehave with some
(typically newer or more exotic) template features, but this is no
different from non-template features.

Cheers
Paavo

[Jorgen Grahn]

That's not how most people use the term. Stroustrup has a rather long
discussion about the difference between generic programming and
template metaprogramming: The C++ Programming Language, 4th ed,
section 28.1. Sorry, I'm too lazy to quote or summarize it.

/Exactly/ where the border between the two goes is, for me personally,
not that interesting.

I hope there isn't a trend to spread fear and doubt about generic
programming, by associating it with template metaprogramming. The
former is obviously useful to almost everyone, and nothing to be
afraid of. The latter is ... well, I haven't quite grasped it in
practice yet.

[Chris Vine]

On Fri, 10 Apr 2015 15:22:18 -0700 (PDT)

Compile time programming using templates is entirely standardized, in
the sense that templates are standardized. It is sometimes said that
TMP is an unexpected side effect of creating a template system
originally intended for "cookie cutting", but it is now well used both
within the standard library and by other libraries. std::tuple for
example is implemented using TMP with recursive inheritance. C++11/14
also provides a complete type trait library providing (amongst other
things) compile time predicates and type transformations.

One implied question that you have asked is the extent to which
compilers correctly implement templates in conformity with the
standard. In my experience, gcc >= 4.8, and clang >= 3.4, are nearly
completely conformant with respect to templates. Earlier versions of
gcc correctly implement type traits (I believe from around gcc-4.3 or
4.4 onwards - it is a long time since I used those compilers) but have
a number of infelicities at the edges. Recent versions of visual
studio are reputed to be more or less completely compliant.

If you are writing an average program, you may never need to know about
or understand TMP. The libraries used by the program will do the work
for you. If you are writing a library for C++11 or C++14 you will
probably at least use the type traits library and quite probably a great
deal more. To take a simple example, if you are forwarding arguments
using C++11/14 "universal"/"collapsible" references, you may well find
yourself needing to use std::remove_reference to convert a deduced
reference type where an lvalue is passed to the underlying type when
instantiating a template. This is trivial to do but would generally be
classed as compile time meta programming.

Chris

[Jorgen Grahn]

On Sun, 2015-04-12, Chris Vine wrote:
...

> Compile time programming using templates is entirely standardized, in
> the sense that templates are standardized. It is sometimes said that
> TMP is an unexpected side effect of creating a template system
> originally intended for "cookie cutting", but it is now well used both
> within the standard library and by other libraries.

And Stroustrup's angle on that is at

http://www.stroustrup.com/bs_faq.html#understand

[Juha Nieminen]

Jorgen Grahn <grahn...@snipabacken.se> wrote:
> "Trickery" implies, as I understand the word, something devious and
> undocumented that you're not supposed to learn about.

I was using the word to mean a technique that's non-trivial, non-obvious
and requires a deeper understanding of how the (template) mechanism
works and, to some extent, using the "side-effect" of a feature to
achieve what you want. (This doesn't mean that using the feature in
that manner is not fully standard.)