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

Why is this here?

[jbrandon]

It's a very basic introduction to a very deep subject. Anyone who knows C++ knows the vast majority of this information.

Plus, the navigation links on the second article are broken.

For some really exciting C++, see www.gotw.ca or www.cuj.com

Those sites have great articles about templates and overloading.

Re:Why is this here?

[orthogonal]

get Andrei Alexandrescu's book Modern C++ Design

Agreed. A mind-blowing book, it will challenge your ideas about how to code.

It's about more than just C++ templates; although its use of templates is revolutionary, the more general and important message of the book is about designing small, re-usable pieces of code that interact gracefully with each other (and to the extent possible, interact at compile-time rather than run-time). These ideas can, in theory, be applied to any langauge that supports class typing; in practice I've used in in pre-generics Java to a small (and non-revolutionary) extent.

If you program in any significant way in C++, you owe it to yourself to get the book, if for no other reason than to re-experience that sense of wonder you felt when you compiled your first program.

Re:Parametric polymophism.

[renehollan]

Why should I care if the language makes it an object or a function as long as it does what I want when I call it?

If a function is a first class object, then you can (a) queue it for later execution, (b) manage an ordered list of functions for execution, (c) partially qualify the parameters for later execution, with the remainder specified at call (i.e. dispatch) time. Read up on functors some time.

Re:Hi fallutin' OO zealots!!!

[renehollan]

Look folks, it's called a function pointer. We've had those in "C" for a long long time, so don't act like you invented it.

A functor is far more than a "function pointer".

A functor lets you fix none, all, or some of the parameters that are to be passed to the function via the pointer to it. This has practial applications. For example, an editor with an "undo" function that dispatches based on queued functors of edit operations, can also implement the "undo" by mapping that queue of functors to a nre queue of functors that do the "undo"ing. Try doing that with a function pointer.

Also, because one has the opportunity to bind the function to it's parameters at different times, they don't all have to be known at the same time.

I've put functors to good use when dispatching encapsulated function calls with queues of functions to call when those calls result in later callbacks in a multithreaded system -- there being a relationship in the dispatched functors and the callback parameters. You really should read Modern C++ Design to develop an appreciation for these techniques. They aren't obvious at first.

Re:why is this newsworthy ?

[wandazulu]

Unless you've done the majority of your C++ programming using VC4.1/4.2/5/6 which doesn't support this feature, but all of a sudden 7.1 does and you want to see what you've been missing.

Re:I mostly disagree

[voodoo1man]

In LISP, macros became so bloated that Scheme had to be invented to strip the language down. But it was too late.

Before flaming, it helps to actually check who, what and why invented Scheme.

Sussman and Steele's compiler was first of all an implementation of Hewitt's ACTORS, and second of all an interpreter that re-wrote Scheme in CPS style (along the way inventing general tail-recursion) targeted at Maclisp. The only "bloat" that Scheme fixed was the "funarg problem" of early lisps by introducing full lexical scoping (along the way inventing the closure) and applicative order reduction/evaluation for function arguments, a convention that most later Lisps adopted (those that did not reportedly disappeared without a trace in the 1980s). The original Scheme did not include macros, and didn't have FEXPRS (ie - all functions evaluated their arguments, as mentioned above), but it did have quote, which is enough to build macros. I'm pretty sure they used some form of macros for transforming special forms to lambdas (off the top of my head, I think Steele mentions dirty macros in Compiler Optimization based on viewing LAMBDA as rename plus GOTO in Winston, ed, Artificial Intelligence - An MIT Perspective, Vol. 2). I know AI Memo 349 (Sussman, Steele, SCHEME an interpteter for extended lambda calculus) mentions something about AMACROs in the implementation.

But certainly neither of them disparaged macros (as a matter of fact, I do recall a not too old discussion on the Lighweight Languages mailing list where Steele defends macros against an attack using the same (lack of) arguments as yours).

PS - yes, it certainly was too late for Scheme, but luckily they added syntax-case back in somewhere around R4RS. Better late than never.