Function Template Specialization in C++

friedo writes "About.com has an excellent two-part article (Part 1, Part 2) by Eric Nagler, author of "Learning C++," about "specializing" function templates in C++. "Rather than specifying an explicit type of all of the arguments or the return value in the definition of a function, placeholders are used. This reduces the need to create and maintain multiple copies of a function for different parameter types. But sometimes, it is not possible to write a single function template that works efficiently or even correctly for every argument type. It is in these cases that function template specialization is useful.""

Comments

Parametric polymophism.

[Daleks]

Why do

template
<typename A, typename B>
A f(B b)
{
...
}

when you can do

let f b = ...

Re:Parametric polymophism.

[renehollan]

But partial application and closures are a extremely painful in C++.

Not surprising, since the two-level nature of C++, via templates is more of an accident rather than a design. There are better languages out there that support these facilities in a clean fashion.

Nevertheless, these are extremely useful and poweful techniques. Every language has it's "dark and ugly" side -- think about the macro hackery you need to support parallel arrays in C.

Re:Why is this here?

[saden1]

Anyone who knows C++ knows the vast majority of this information.

How pretentious of you to assume this. Most people don't even know how write a template function let alone write a single function template that works for every argument type. I found this artical very informative and definitely worth the read.

Re:Why is this here?

[dthable]

A lot of people are in this boat of thinking of C++ as C with classes. Unless you really got into the last standard or had a need to use templates, STL, namespaces, etc. there was never a need to learn them.

But hey, would you expect any less from /.?

Re:Horrible example

[renehollan]

This is a perfect example of how NOT to use the expressive power of C++.

Oh, I wholeheartedly disagree!

Any junior programmer I encountered who was interested in generic programming would get my greatest support, and gentle guidance. I might not permit his initial attempts in production code, but I wouldn't stifle his interest either. How the hell else is a programmer supposed to mature their art?

Yes, it's real easy to fuck yourself up a million ways from Sunday, and none of them good, when you try to exploit a language mechanism that provides a two level language, with selective binding, but the power is immense. Just look at the use of C++ template metaprogramming for compile-time optimization -- it solves the cost of abstraction problem.

The syntax sucks, of course, and that makes it hard to comprehend, but that's to be expected when the Turing completeness of a language facility comes not by design, but by accident.

Ideally, in any project architects define the desirable coding abstractions, senior programmers implement the support for them, and more junior programmers code using them -- there is no more need for a junior programmer to understand template arcana than there is for them to understand the building of glibc (which is a either a horrid abuse of make, or a beautiful hack, depending on your point of view -- xargs is your friend).

When you strive to reducing all the code your team writes to that understandable by the lowest common denominator of skill available, you compress the scale of productivity exhibited by your team members greatly. Given that coding productivities can vary by an order of magnitude within a team (some have said, this really isn't something you want to do.

Instead you should build layers of abstraction, including meta languages within your code, giving the difficult implementations to the senior members, and the simpler ones (considering also the abstractions you've built) to more junior ones.

Part of the problem with your complaint is that you continue to see pointers to NUL-terminated character arrays instead of strings, right down to your pseudo-Hungarian notation. The whole idea is not to compare pointers, but strings, with the pointer implementation of a handle to the first character of the string a string implementation detail, ideally hidden.

It just gets even more convoluted

[Viol8]

The problem with C++ and swith this concept , is that it makes things quicker for the intial programmer but a DAMN site harder for a
maintenance programmer to understand.

If I see:
A var1;
B var2;
var3 = var1 + var2;

in the middle of a C++ program I have NO idea what the hell is going on unless I trawl through reams of
definitions to find out what the templates were set to and how the operator was overloaded. Sorry , but this isn't progress , its obfuscation.
Give me more lines of duplicate code with obvious definitions instead of templates and overloads everywhere.

Re:It just gets even more convoluted

[Viol8]

Actually I was thinking more:

class foobar var1;
class wibble var2;

var3 = concatenateNames(&var1, &var2);

Or something like that. If people only ever used operators for their namesake operations there wouldn't be a problem but how often have you seen
code where + is overloaded to do all sorts of different operations depending on the STATE of what gets passed to it, never mind
the actual types that get passed.

"operator overloading is just syntactic sugar for a function call: it's no more and no less obfuscated"

That may be true , but using your example its a damn site easier to grep through some source code for "add(" and get maeningfull output than for
the + operator!

Re:It just gets even more convoluted

[renehollan]

I have NO idea what the hell is going on unless I trawl through reams of definitions to find out what the templates were set to and how the operator was overloaded

...unless you understand the types A and B, and the meaning of operator+(const A&, const B&). If A and B represented arbitrary precision numbers, it would be perfectly natural to use operator+ for their addition.

The counter to your objection is that if you don't understand the types in a program, you've got no business messing with objects of those types. That is not an argument against user-defined objects or operator overloading, but one for proper architecture with no extraneous types or templates.

Basically, these mechanisms make it easier to use the implementation language to express code architecture and design pattern models -- programming at a higer level of abstraction if you will, but programming nevertheless. The trouble is that many so-called "programmers" lack the skill to do this and get miffed.

Re:It just gets even more convoluted

[Mr. Slippery]

Seriously, operator overloading is just syntactic sugar for a function call: it's no more and no less obfuscated.

True, but in my experience operator overloading is more subject to abuse. With a function, the devloper has to give it a name, and the potential namespace is much larger than the operator namespace.

Re:Horrible example

[renehollan]

Indeed. The pointer to NUL-terminated sequence of characters is sooo idiomatically a string from the "C days", that it's probably more understandable to preserve that idiom than not. Heck, that's the only way to implement string literals without the use of an object, and we know how much we love our string literals.

I suppose if I were to implement the template, I'd have a greater member function that throws an exception when passed a pointer, with a partial specialization that works for pointers to chars (unsigned chars, const chars, const unsigned chars). The only grief with this approach is that you can't partially specialize non-member function templates and must resort to a class.

Another marginal C++ feature

[Animats]

There's a group of C++ programmers who are into abusing the template mechanism into a compile-time programming environment. This is not a good thing.

The most impressive perversion of this ilk is the Blitz numeric library. This does loop unrolling by using the template library as a term-rewriting system. The resulting code is very complex, hard to debug, and of marginal value. Blindly unrollilng loops without understanding the target architecture at the instruction level is a lose on many modern superscalar machines. Newer machines tend to do loops faster than straight-line code.

Debugging compile-time processing in C++ is tough. You can't step through the process, you can't print anything, and the compiler doesn't provides any output about what's going on. Programming at compile time has a long, sordid history (LISP macros come to mind), and C++ is an inferior environment for it anyway.

If you're using a compiler which will develop templates in-line, decide if-statements at compile time, and discard unreachable code (which includes most modern compilers), it's better to write code which works that way, rather than use template specialization.

But obvious (or not) to whom?

[Anonymous Brave Guy]

You really should read Modern C++ Design to develop an appreciation for these techniques. They aren't obvious at first.

In fairness, while MC++D is indeed an interesting book for the serious C++ hacker, one should bear in mind (as the original post to this subthread pointed out) that most of the clever function stuff in it is second nature in a functional language, wherein it is obvious and a typical programmer will achieve much the same goals with far less obfuscation and much more concise code.

I've noticed that a lot of the "leading edge" C++ tools, from the STL to Loki and Boost, are pretty much trying to implement programming tools from other languages that have demonstrated value -- higher order functions, automatic resource management, high performance mathematics, complex data structures, regular expressions -- within C++. There's nothing wrong with that, of course, but the underlying techniques aren't particularly clever if you're familiar with languages that specialise in them.

Every day, as I work on a complex mathematical library written in C++, I internally groan at writing five times as many lines of code as I'd need in any major functional language because C++ has such weak support for a couple of key areas that we use all the time. The practicalities of our situation may make it the most appropriate tool we've found for the job, but looking at templates, macro hackery or cute inheritance graphs doesn't stop me wishing I could use higher order functions when working with complex mathematics...

Re:Is this even correct C++?

[renehollan]

Again, there is no partial specialization what so ever in his examples. Partial specialization involves pointers and references to unknown types. Of which there is none in the examples. Partial specialization does not mean part of full specialization.

WQe are not talking about the same thing. Consider the class template:

template <typename T, typename U> class X { ... };

This can be partially specialised thus:

template <typename U> class X<int, U> { ... };

and fully thus:

class X<int, long> { ... };

or template <> class X<int, long> { ... };

though, technically the last example above is an explicit specialization, whereas the one above it is a full specialization.

You're talking about cases like

template <typename T> class X<T, T&> { ... }

which are also partial template specializations.

But, I reiterate, you can't partially specialize member functions or non-member functions in the same way -- you can only totally specialize member functions and use overloading for non-member functions to similar effect. I recall that the syntax for non-member functions allows a fully-specialized template syntax to be used (instead of simple signature overloading), but I may be mistaken there.

So,

template <typename T, typename U> void f(T t, U u) { ... }

void f(int t, long u)<int, long> { ... }

as opposed to simply

void f (int t, long u) { ... }

The first would be a full specialization and the latter a simple overload. Something in my mind tells me that the full specialization function syntax is, in fact, legal, though I don't have the time to try it now.

See Alaxandrescu, Andrei, "Modern C++ Design", Addison-Wesley, New York, 2001, pp. 26-28.