Nicolás Brailovsky » Templates http://nicolasb.com.ar A modern blog Tue, 20 Dec 2011 09:00:54 +0000 en hourly 1 http://wordpress.org/?v=3.3 Cool C++0X features XII: type inference with auto http://nicolasb.com.ar/2011/10/cool-c0x-features-xii-type-inference-with-auto/ http://nicolasb.com.ar/2011/10/cool-c0x-features-xii-type-inference-with-auto/#comments Tue, 04 Oct 2011 10:00:17 +0000 nico http://nicolasb.com.ar/?p=1399 In the last four entries we worked on a simple example, like the one I’m pasting below, of type inference with decltype, which led us to learn about delayed type declaration and decltypes with auto. This time I want to focus just on the auto keyword instead.

  1. template <class… Args>
  2. auto wrap(Args… a) -> decltype( do_something(a…) ) {
  3.         std::cout << __PRETTY_FUNCTION__ << "\n";
  4.         return do_something(a…);
  5. }

We saw last time how decltype can be used in a contrived way to create a local variable without specifying its type, only how to deduce the type for this variable. Luckily, that verbose method of type declaration can be summed up in the following way:

  1.         int x = 2;
  2.         int y = 3;
  3.         decltype(x*y) z = x*y;
  1.         int x = 2;
  2.         int y = 3;
  3.         auto z = x*y;

That’s right, when you are declaring local variables it’s easier and cleaner to just use auto. This feature isn’t even “in the wild” yet, so you can’t really predict what will people do with it, but it seems to me that limiting its use to local variables with a very short lived scope is the best strategy. We are yet to see what monstrosities the abuse of this feature will produce, and I’m sure there will be many. Regardless of their potential to drive insane any maintainers, its best use probably comes in loops.

In any C++ application, you’ll find code like this:

  1. for (FooContainer<Bar>::const_iterator i = foobar.begin(); i != foobar.end(); ++i)

This ugly code can be eliminated with something much more elegant:

  1. for (auto i = foobar.begin(); i != foobar.end(); ++i)

Looks nicer indeed, but we can improve it much further with other tools. We’ll see how the next time. For the time being, let’s see for waht what auto is not to be used.

When using auto, keep in mind it was designed to simplify the declaration of a variable with a complex or difficult to reason type, not as a replacement for other language features like templates. This is a common mistake:

Wrong

  1. void f(auto x) {
  2.         cout << x;
  3. }
 Right

  1. template <T>
  2. void f(T x) {
  3.         cout << x;
  4. }

It makes no sense to use auto in the place of a template, since a template means that the type will be completed later whereas auto means it should be deduced from an initializer.

]]> http://nicolasb.com.ar/2011/10/cool-c0x-features-xii-type-inference-with-auto/feed/ 0 Cool C++0X features X: type inference with decltype http://nicolasb.com.ar/2011/06/cool-c0x-features-x-type-inference-with-decltype/ http://nicolasb.com.ar/2011/06/cool-c0x-features-x-type-inference-with-decltype/#comments Fri, 10 Jun 2011 10:00:46 +0000 nico http://nicolasb.com.ar/?p=1395 After creating a wrapper object on the last entries, we were left with three syntax changes two analyze:

We already saw the first, and we’ll be talking about the other two this time. This was the original wrapper function which led us here:

  1.  
  2. template <class… Args>
  3. auto wrap(Args… a) -> decltype( do_something(a…) ) {
  4.         std::cout << __PRETTY_FUNCTION__ << "\n";
  5.         return do_something(a…);
  6. }
  7.  

Back on topic:

decltype
This operator (yes, decltype is an operator) is a cousin of sizeof which will yield the type of an expression. Why do I say it’s a cousin of sizeof? Because it’s been in the compilers for a long time, only in disguise. This is because you can’t get the size of an expression without knowing it’s type, so even though it’s implementation has existed for a long time only now it’s available to the programmer.

One of it’s interesting features is that the expression with which you call decltype won’t be evaluated, so you can safely use a function call within a decltype, like this:

  1.  
  2. auto foo(int x) -> decltype( bar(x) ) {
  3.         return bar(x);
  4. }
  5.  

Doing this with, say, a macro, would get bar(x) evaluated twice, yet with decltype it will be evaluated only once. Any valid C++ expression can go within a decltype operator, so for example this is valid too:

  1.  
  2. template <typename A, typename B>
  3. auto multiply(A x, B y) -> decltype( x*y )
  4. {
  5.         return x*y;
  6. }
  7.  

What’s the type of A and B? What’s the type of A*B? We don’t care, the compiler will take care of that for us. Let’s look again at that example, more closely:

-> (delayed declaration) and decltype

Why bother creating a delayed type declaration at all and not just use the decltype in place of the auto? That’s because of a scope problem, see this:

  1.  
  2. // Declare a template function receiving two types as param
  3. template <typename A, typename B>
  4. // If we are declaring a multiplication operation, what’s the return type of A*B?
  5. // We can’t multiply classes, and we don’t know any instances of them
  6. auto multiply(A x, B y)
  7. // Luckily, the method signature now defined both parameters, meaning
  8. // we don’t need to expressly know the type of A*B, we just evaluate
  9. // x*y and use whatever type that yields
  10.         -> decltype( x*y )
  11. {
  12.         return x*y;
  13. }
  14.  

decltype
As you see, decltype can be a very powerful tool if the return type of a function is not known for the programmer when writing the code, but you can use it to declare any type, anywhere, if you are too lazy to type. If you, for example, are very bad at math and don’t remember that the integers group is closed for multiplication, you could write this:

  1.  
  2.         int x = 2;
  3.         int y = 3;
  4.         decltype(x*y) z = x*y;
  5.  

Yes, you can use it as VB’s dim! (kidding, just kidding, please don’t hit me). Even though this works and it’s perfectly legal, auto is a better option for this. We’ll see that on the next entry.

]]> http://nicolasb.com.ar/2011/06/cool-c0x-features-x-type-inference-with-decltype/feed/ 0 Cool C++0X features IX: delayed type declaration http://nicolasb.com.ar/2011/06/cool-c0x-features-ix-delayed-type-declaration/ http://nicolasb.com.ar/2011/06/cool-c0x-features-ix-delayed-type-declaration/#comments Tue, 07 Jun 2011 10:00:44 +0000 nico http://nicolasb.com.ar/?p=1392 In the last two entries we worked on a wrapper object which allows us to decorate a method before or after calling (hello aspects!), or at least that’s what it should do when g++ fully implements decltypes and variadic templates. Our wrapper function looks something like this (check out the previous entry for the wrapper object):

  1.  
  2. #include <iostream>
  3.  
  4. void do_something() { std::cout << __PRETTY_FUNCTION__ << "\n"; }
  5. void do_something(const char*) { std::cout << __PRETTY_FUNCTION__ << "\n"; }
  6. int do_something(int) { std::cout << __PRETTY_FUNCTION__ << "\n"; return 123; }
  7.  
  8. template <class… Args>
  9. auto wrap(Args… a) -> decltype( do_something(a…) ) {
  10.         std::cout << __PRETTY_FUNCTION__ << "\n";
  11.         return do_something(a…);
  12. }
  13.  
  14. int main() {
  15.         wrap();
  16.         wrap("nice");
  17.         int x = wrap(42);
  18.         std::cout << x << "\n";
  19.         return 0;
  20. }
  21.  

After the example, we were left with three new syntax changes to analyze:

  • -> (delayed declaration)
  • decltype
  • auto

Let’s study the -> operator this time:

-> (delayed declaration)
This is the easiest one. When a method is declared auto (I’ve left this one for the end because auto is used for other things too) it means its return type will be defined somewhere else. Note that in this regard the final implementation differs from Stroustroup’s FAQ.

The -> operator in a method’s definition says “Here’s the return type”. I’ll paste the same simple example we had last time, the following two snippets of code are equivalent:

  1.  
  2. void foo() {
  3. }
  4.  
  1.  
  2. auto foo() -> void {
  3. }
  4.  
]]> http://nicolasb.com.ar/2011/06/cool-c0x-features-ix-delayed-type-declaration/feed/ 1 Cool C++0X features VIII: Variadic wrapper and type inference with decltype http://nicolasb.com.ar/2011/05/cool-c0x-features-viii-variadic-wrapper-and-type-inference-with-decltype/ http://nicolasb.com.ar/2011/05/cool-c0x-features-viii-variadic-wrapper-and-type-inference-with-decltype/#comments Tue, 31 May 2011 10:00:08 +0000 nico http://nicolasb.com.ar/?p=1388 The wrapper function we built last time looks something like this now:

  1. #include <iostream>
  2.  
  3. void do_something() { std::cout << __PRETTY_FUNCTION__ << "\n"; }
  4. void do_something(const char*) { std::cout << __PRETTY_FUNCTION__ << "\n"; }
  5.  
  6. template <class… Args>
  7. void wrap(Args… a) {
  8.         std::cout << __PRETTY_FUNCTION__ << "\n";
  9.         do_something(a…);
  10. }
  11.  
  12. int main() {
  13.         wrap();
  14.         wrap("nice");
  15.         return 0;
  16. }

But, as we saw last time, this approach has the problem of requiring the return type of do_something to be known before hand. What can we do to remove this dependency? In C++, not much. You can’t really declare a type based on the return type of another function. You do have the option of using lots of metaprogramming wizardy, but this is both error prone and ugly (see Stroustroup’s C++0x FAQ).

C++0x lets you do some magic with type inference using decltype; decltype(expr) will yield the type of that expression. It works quite similarly as sizeof does; decltype is resolved at compile time and the expression with which it’s being called is not evaluated (more on this later).

How would this work on our example?

  1. #include <iostream>
  2.  
  3. void do_something() { std::cout << __PRETTY_FUNCTION__ << "\n"; }
  4. void do_something(const char*) { std::cout << __PRETTY_FUNCTION__ << "\n"; }
  5. int do_something(int) { std::cout << __PRETTY_FUNCTION__ << "\n"; return 123; }
  6.  
  7. template <class… Args>
  8. auto wrap(Args… a) -> decltype( do_something(a…) ) {
  9.         std::cout << __PRETTY_FUNCTION__ << "\n";
  10.         return do_something(a…);
  11. }
  12.  
  13. int main() {
  14.         wrap();
  15.         wrap("nice");
  16.         int x = wrap(42);
  17.         std::cout << x << "\n";
  18.         return 0;
  19. }

Try it (remember to add -std=c++0x) it works great! The syntax is not so terribly difficult to grasp as it was with variadic templates. The auto keywords says “hey, compiler, the return type for this method will be defined later”, and then the -> actually declares the return type. This means that the auto-gt idiom isn’t part of typedecl but a helper, which in turns means that even if not useful, this is valid C++0x code:

  1. auto wrap() -> void {
  2. }

This means that we have three interesting components to analyze in this scenario:

  • -> (delayed declaration)
  • auto
  • decltype

We’ll go over each one the next time.

Closing remark:

At first I choose the following example to introduce delayed return types and decltype (warning, untested code ahead):

  1. #include <iostream>
  2.  
  3. struct Foo {
  4.         void do_something() { std::cout << __PRETTY_FUNCTION__ << "\n"; }
  5.         void do_something(const char*) { std::cout << __PRETTY_FUNCTION__ << "\n"; }
  6.         int do_something(int) { std::cout << __PRETTY_FUNCTION__ << "\n"; return 123; }
  7. };
  8.  
  9. // Untested code ahead
  10. // This makes g++ coredump (v 4.4.5)
  11. template <class T>
  12. struct Wrap : public T {
  13.         template <class… Args>
  14.         auto wrap(Args… a) -> decltype( T::do_something(a…) ) {
  15.                 std::cout << __PRETTY_FUNCTION__ << "\n";
  16.                 return T::do_something(a…);
  17.         }
  18. };
  19.  
  20. int main() {
  21.         Wrap<Foo> w;
  22.         w.wrap();
  23.         w.wrap("nice");
  24.         std::cout << w.wrap(42) << "\n";
  25.         return 0;
  26. }

Though this looks MUCH better (and useful), at the time of writing this article mixing variadic templates with decltypes in a template class makes g++ segfault. It should be valid C++, but I can’t assure it’s correct code since I’ve never tried it.

]]> http://nicolasb.com.ar/2011/05/cool-c0x-features-viii-variadic-wrapper-and-type-inference-with-decltype/feed/ 0 Cool C++0X features VII: A variadic wrapper solution http://nicolasb.com.ar/2011/05/cool-c0x-features-vii-a-variadic-wrapper-solution/ http://nicolasb.com.ar/2011/05/cool-c0x-features-vii-a-variadic-wrapper-solution/#comments Tue, 24 May 2011 10:00:36 +0000 nico http://nicolasb.com.ar/?p=1385 Last time we were trying to build a wrapper function, in which we don’t control the class being wrapped nor the user of the wrapper (meaning we can’t change either of those but they could change without warning).

This was the first approach:

  1. #include <iostream>
  2.  
  3. void do_something() { std::cout << __PRETTY_FUNCTION__ << "\n"; }
  4.  
  5. void wrap() {
  6.         std::cout << __PRETTY_FUNCTION__ << "\n";
  7.         do_something();
  8. }
  9.  
  10. int main() {
  11.         wrap();
  12.         return 0;
  13. }

Yet, as we saw, it’s not scalable, when either part changes the whole things break. We proposed then a variadic template solution, which, if you tried it yourself, should look something like this:

  1. #include <iostream>
  2.  
  3. void do_something() { std::cout << __PRETTY_FUNCTION__ << "\n"; }
  4. void do_something(const char*) { std::cout << __PRETTY_FUNCTION__ << "\n"; }
  5.  
  6. template <class… Args>
  7. void wrap(Args… a) {
  8.         std::cout << __PRETTY_FUNCTION__ << "\n";
  9.         do_something(a…);
  10. }
  11.  
  12. int main() {
  13.         wrap();
  14.         wrap("nice");
  15.         return 0;
  16. }

That’s better. Now we don’t care about which parameters do_something should get, nor how many of them are there supposed to be, just how it’s called. If you read the previous entries on variadic templates this should be a walk in the park. It still has a flaw though: we need to know the return type of do_something!

Is there a way to write a wrapper without knowing the return type of a function you are wrapping? Yes, in Ruby you can, but you can do it in C++0x too, and we’ll see how to do it next time.

A closing remark: You could do something like this wrapping everything in a class:

  1. #include <iostream>
  2.  
  3. struct Foo {
  4.         void do_something() { std::cout << __PRETTY_FUNCTION__ << "\n"; }
  5.         void do_something(const char*) { std::cout << __PRETTY_FUNCTION__ << "\n"; }
  6. };
  7.  
  8. template <class Base>
  9. struct Wrapper : public Base {
  10.         template <class… Args>
  11.         void wrap(Args… a) {
  12.                 std::cout << __PRETTY_FUNCTION__ << "\n";
  13.                 Base::do_something(a…);
  14.         }
  15. };
  16.  
  17. int main() {
  18.         Wrapper<Foo> w;
  19.         w.wrap();
  20.         w.wrap("nice");
  21.         return 0;
  22. }

The above works just fine, but due to some limitations in the current (stable) version of gcc we will use the former version (the problem with this form will be clear later, I promise).

]]> http://nicolasb.com.ar/2011/05/cool-c0x-features-vii-a-variadic-wrapper-solution/feed/ 0 Cool C++0X features VI: A variadic wrapper http://nicolasb.com.ar/2011/05/cool-c0x-features-vi-a-variadic-wrapper/ http://nicolasb.com.ar/2011/05/cool-c0x-features-vi-a-variadic-wrapper/#comments Tue, 17 May 2011 10:00:12 +0000 nico http://nicolasb.com.ar/?p=1381 Let’s work on the last variadic exercise, a wrapper. Say you have something like this:

  1.  
  2. #include <iostream>
  3.  
  4. void do_something() { std::cout << __PRETTY_FUNCTION__ << "\n"; }
  5.  
  6. int main() {
  7.         do_something();
  8.         return 0;
  9. }
  10.  

And you want to wrap do_something with something else (Remember __PRETTY_FUNCTION__?). This is a solution, the worst one though:

  1.  
  2. #include <iostream>
  3.  
  4. void do_something() { std::cout << __PRETTY_FUNCTION__ << "\n"; }
  5.  
  6. void wrap() {
  7.         std::cout << __PRETTY_FUNCTION__ << "\n";
  8.         do_something();
  9. }
  10.  
  11. int main() {
  12.         wrap();
  13.         return 0;
  14. }
  15.  

Why is it so bad? Let’s say you don’t control do_something, you just control the wrapper. You may not even control main(), it may be beyond your scope. That means each time do_something changes, or adds an overload, you have to change your code. That’s ugly and you should already know how to set up a variadic function to forward the arguments to do_something. Give it a try, next time the solution.

]]> http://nicolasb.com.ar/2011/05/cool-c0x-features-vi-a-variadic-wrapper/feed/ 0 Cool C++0X features V: Templates and angle brackets, a short interlude http://nicolasb.com.ar/2011/05/cool-c0x-features-v-templates-and-angle-brackets-a-short-interlude/ http://nicolasb.com.ar/2011/05/cool-c0x-features-v-templates-and-angle-brackets-a-short-interlude/#comments Tue, 10 May 2011 10:00:29 +0000 nico http://nicolasb.com.ar/?p=1363 In the heart of C++ template metaprogramming and code obfuscation, lies the (ab)use of angle brackets. This seemingly innocent token can turn the most clean looking code into the mess that template-detractors like so much to complain about.

C++0x doesn’t do much to clean up this mess, it’s probably impossible, but it does offer a subtle feature to improve the legibility of C++ template code, a nifty little feature we have (inadvertently) used.

Up to C++0x, having two angle brackets together (>>) was parsed as the shift operator (like the one cout uses), meaning that if you had nested templates a lot of compiler errors ensued. C++0x corrects this, meaning that code which in C++ would be like this:

  1.         Reduce<Sum, Lst<Num<2>, Lst<Num<4>, Lst<Num<6>, Lst< Num<8> > > > > >

Can now be written like this:

  1.         Reduce<Sum, Lst<Num<2>, Lst<Num<4>, Lst<Num<6>, Lst< Num<8>>>>>>

Aaand, back to the normal programming…

]]> http://nicolasb.com.ar/2011/05/cool-c0x-features-v-templates-and-angle-brackets-a-short-interlude/feed/ 0 Cool C++0X features IV: Variadic templates again http://nicolasb.com.ar/2011/05/cool-c0x-features-iv-variadic-templates-again/ http://nicolasb.com.ar/2011/05/cool-c0x-features-iv-variadic-templates-again/#comments Tue, 03 May 2011 10:00:49 +0000 nico http://nicolasb.com.ar/?p=1361 Last time we finally solved the varargs problem. Let’s review what we learned:

  • Variadic templates let us create something receiving a variable set of arguments
  • We can process the head of that set, then recursively process the tail
  • It adds weird new syntax
    • When declaring typename… T you are saying “here goes a list of types”
    • When declaring T… t you are saying t is a list of objects with different type
    • When you write t…, you are saying “expand the list of arguments”
  • It’s type safe
  • It’s very neat to confuse your coworkers

So, what can we do with it besides implementing our own version of printf? Let’s do something better, let’s try adding up a list of numbers to start flexing our variadic templatefooness (?).

What’s the usual way of adding a list of numbers? In templates, that is. We need something like this:

  1. sum (H:T) <- H + sum(T)
  2. sum () <- 0

Of course, in C++ templates you don’t have values, you just have types. We could implement it like this (if this looks like a new language you may want to check my template metaprogramming series):

  1. #include <iostream>
  2.  
  3. struct Nil{};
  4. template <typename H, typename T=Nil> struct Lst {
  5.         typedef H Head;
  6.         typedef T Tail;
  7. };
  8.  
  9. template <
  10.                 template<typename A, typename B> class Op,
  11.                 typename Head,
  12.                 typename Lst>
  13. struct intForeach
  14. {
  15.         typedef typename intForeach
  16.                 < Op, typename Lst::Head, typename Lst::Tail >::result Next;
  17.         typedef typename Op< Head, Next >::result result;
  18. };
  19.  
  20. template <
  21.                 template<typename A, typename B> class Op,
  22.                 typename Head>
  23. struct intForeach <Op, Head, Nil>
  24. {
  25.         typedef Head result;
  26. };
  27.  
  28. template <
  29.                 typename Lst,
  30.                 template<typename A,
  31.                 typename B>
  32.                 class Op>
  33. struct Reduce
  34. {
  35.         typedef typename intForeach
  36.                 < Op, typename Lst::Head, typename Lst::Tail >::result result;
  37. };
  38.  
  39. template <int N> struct Num {
  40.         const static int value = N;
  41. };
  42.  
  43. template <typename A, typename B> struct Sum {
  44.         static const int r = A::value + B::value;
  45.         typedef Num<r> result;
  46. };
  47.  
  48. int main() {
  49.         std::cout << Reduce<
  50.                 Lst<Num<2>, Lst<Num<4>, Lst<Num<6>, Lst< Num<8> > > > >,
  51.                 Sum >::result::value << "\n";
  52.         return 0;
  53. }

Nothing too fancy, plain old recursion with a sum. Yet it’s quite verbose, can we make this a little bit more terse and, hopefully, more clear? Yes, we can. Take a look at that Lst, Lst<… It sucks. And it’s the perfect place to use variadic templates, we just need to construct a structure getting a list of ints, like this:

  1. template <
  2.         // The operation we wish to apply
  3.         template<typename A, typename B> class Op,
  4.         // Current element to process
  5.         class H,
  6.         // All the rest
  7.         class… T>
  8. struct Reduce_V
  9. {
  10.         // TODO
  11. }

That one should look familiar from last time article. Now, to implement a reduce operation we need to operate the current element with the result of reducing the tail, so we have to do something like this:

  1.         // Remember how T… means to expand T for the next instance
  2.         typedef typename Reduce_V<Op, T…>::result Tail_Result

There’s something missing. Can you see what? The ending condition, of course. Let’s add it and we’ll get something like this:

  1.  
  2. template <
  3.         // The operation we wish to apply
  4.         template<typename A, typename B> class Op,
  5.         // All the rest
  6.         class… T>
  7. struct Reduce_V
  8. {
  9. };
  10.  
  11. template <
  12.         // The operation we wish to apply
  13.         template<typename A, typename B> class Op,
  14.         // All the rest
  15.         class H>
  16. struct Reduce_V<Op, H>
  17. {
  18.         typedef H result;
  19. };
  20.  
  21. template <
  22.         // The operation we wish to apply
  23.         template<typename A, typename B> class Op,
  24.         // Current element to process
  25.         class H,
  26.         // All the rest
  27.         class… T>
  28. struct Reduce_V<Op, H, T…>
  29. {
  30.         // Remember how T… means to expand T for the next instance
  31.    typedef typename Reduce_V<Op, T…>::result Tail_Result;
  32.  
  33.    // Reduce current value with the next in line
  34.    typedef typename Op<H, Tail_Result>::result result;
  35. };
  36.  

And using it is very simple too:

  1. std::cout << Reduce_V< Sum, Num<1>, Num<2>, Num<3>, Num<4>>::result::value << "\n";

Next time we’ll see another example for variadic templates and a new C++0x feature.

]]> http://nicolasb.com.ar/2011/05/cool-c0x-features-iv-variadic-templates-again/feed/ 0 Cool C++0X features III: Variadic templates, a fix for varargs http://nicolasb.com.ar/2011/04/cool-c0x-features-iii-variadic-templates-a-fix-for-varargs/ http://nicolasb.com.ar/2011/04/cool-c0x-features-iii-variadic-templates-a-fix-for-varargs/#comments Tue, 26 Apr 2011 10:00:10 +0000 nico http://nicolasb.com.ar/?p=1358 Last time we saw why a function with varargs may bring lots of problems. Then we saw how to solve it, but never explained why that last solution doesn’t have the problems the varargs solution had, nor how does it work. Let’s start by copying the solution here:

  1. // Stop condition
  2. void println() {}
  3.  
  4. // General case
  5. template <typename H, typename… T>
  6. void println(H p, T… t)
  7. {
  8.    std::cout << p;
  9.    println(t…);
  10. }
  11.  
  12. int main() {
  13.    println("Hola", " mundo ", 42, ‘\n‘);
  14.    return 0;
  15. }
  16.  

It certainly looks much better than the varargs function, even though some new strange syntax has been introduced. Keep in mind some template-foo is required, not only because of the syntax but because we’ll be talking about functional programming too.

With all that intro (the last 2 articles were just an intro!) now we are in a good shape to ask what a variadic template really is. In its easiest form, it’s just a list of template arguments, like this:

  1. template <typename… T> void foo(T… t) {}
  2.  

That simple template can accept as many parameters as you need, of any type. This is much safer than a vararg because:

  • Doesn’t require the user to specify the number of args passed to foo, so it just can’t get out of sync
  • It’s typesafe; since C++ templates are type-safe, variadic templates are type safe too. You won’t be able to request an int where a char is required, you’ll just get a compiler error.
  • Compile time check: you get type safety just because this is all compiled code. If it doesn’t compile, you get an error (albeit a little cryptic).
  • POD types support
  • Better performance; small gain, but a gain indeed. Since this is all done in compile time there’s no need to handle the stack dynamically, nor of having a loop getting the args. It’s all known when you compile, thus the compiler can just optimize the hell out of everything

Pretty neat, huh? But how does it work? Variadic templates are actually very similar to how Haskell handles lists, you get all the arguments as a list of types in which you can either get the head or the tail. To do something useful, get the head and continue processing the tail recursively.

  1. template <typename H, typename… T>
  2. void do_something(H h, T… t)
  3. {
  4.         // Do something useful with h
  5.         really_do_something(h);
  6.         // Continue processing the tail
  7.         do_something(t…);
  8. }
  9.  

Of course, you’ll eventually need a condition to stop processing: (we’ll explain the new syntax later)

  1. void do_something()
  2. {
  3.         // Do nothing :)
  4. }
  5.  

When the list is completely processed the empty do_something function will be called. Easy, right? But it does have a lot of weird syntax. Let’s see what each of those ellipses mean:

  • When declaring typename… T you are saying “here goes a list of types”. That is, when you use ellipses after the typename (or class) declaration but before the name of the type, then you are expecting a list of types there.
  • When declaring T… t you are saying t is a list of objects with different type. That is, you declared T… as a type which holds a list of types, therefore t, of type T, is an instance of a list of objects, each of different type
  • When you write t…, you are saying “expand the list of arguments”. You declared t as a list of objects, but you have no way of accessing each of those objects, just to the list as a whole. When you write the name of the object followed by ellipses, you are saying expand these types and their instance for the called function

With all that in mind, let’s put together our typesafe printf:

  1. // Condition to stop processing
  2. void println() {}
  3.  
  4. // Println receieves a list of arguments. We don’t know it’s type nor
  5. // how many there are, so we just get the head and expand the rest
  6. template <typename H, typename… T>
  7. void println(H p, T… t)
  8. {
  9.         // Do something useful with the head
  10.         std::cout << p;
  11.         // Expand the rest (pass it recursively to println)
  12.         println(t…);
  13. }
  14.  
  15. int main() {
  16.         // See how it works even better than varargs?
  17.    println("Hola", " mundo ", 42, ‘\n‘);
  18.    return 0;
  19. }
  20.  

Next time, we’ll see a more complex (and fun) example of variadic templates.

]]> http://nicolasb.com.ar/2011/04/cool-c0x-features-iii-variadic-templates-a-fix-for-varargs/feed/ 0 Cool C++0X features II, Variadic templates: What’s wrong with varargs http://nicolasb.com.ar/2011/04/cool-c0x-features-ii-variadic-templates-whats-wrong-with-varargs/ http://nicolasb.com.ar/2011/04/cool-c0x-features-ii-variadic-templates-whats-wrong-with-varargs/#comments Tue, 19 Apr 2011 10:00:12 +0000 nico http://nicolasb.com.ar/?p=1353 Last time we explained what variadic templates are. We’ll see what they can do now. We mentioned that solving the problem of having a type-safe varargs is one of the best ways of applying variadic templates, but what’s varargs?

Varargs functions (from C world, not even from C++!) are functions which have a variable number of arguments, just like printf. These are usually very dangerous functions, since they are not typesafe. Let’s see how they are implemented with an example:

  1. #include <stdarg.h>
  2. #include <iostream>
  3.  
  4. // My god, it’s full of bugs
  5. void va_println(int args_left, …) {
  6.    va_list arg_lst;
  7.    va_start(arg_lst, args_left);
  8.  
  9.    while(args_left–) {
  10.       const char *p = va_arg(arg_lst, const char*);
  11.       std::cout << p;
  12.    }
  13.  
  14.    va_end(arg_lst);
  15. }
  16.  
  17. int main() {
  18.    va_println(3, "Hola ", "mundo", "\n");
  19.    return 0;
  20. }

This implementation of a function with variable arguments is, more or less, the best C can give us, yet it riddled with bugs and hidden problems. Let’s go one by one:

Arg num will get out of sync
You need to specify the list of args as well as how many you have. That WILL get out of sync. Trust me, it’s just a mater of time. And when it does, you’ll have a coredump.

Type-unsafe
You just tell varargs “Hey, get me an int”. And it will give you an int, no warranties included. If it was supposed to be a short instead, though luck, you end up with a coredump.

No, really, coredump
Where are so many coredumps coming from, you may ask. Easy, varargs it’s just a way of handling the stack. Calling va_arg just moves the stack pointer by the sizeof the datatype you requested. That means no compile-time checks are included.

No pod types
Remember POD types? Try running this code:

  1. #include <stdarg.h>
  2. struct X { virtual ~X(){} };
  3. void va_println(int args_left, …) {
  4.    va_list arg_lst;
  5.    va_start(arg_lst, args_left);
  6.  
  7.    while(args_left–) {
  8.       X *p = va_arg(arg_lst, X*);
  9.    }
  10.  
  11.    va_end(arg_lst);
  12. }
  13.  
  14. int main() {
  15.    X x, y, z;
  16.    va_println(3, x, y, z);
  17.    return 0;
  18. }

And how do we fix it?
The fix is easy. Too easy. You just need C++0X. We will discuss why this is better next time, but just as a sneak peak:

  1. void println() {}
  2. template <typename H, typename… T> void println(H p, T… t) {
  3.    std::cout << p;
  4.    println(t…);
  5. }
  6.  
  7. int main() {
  8.    println("Hola", " mundo ", 42, ‘\n‘);
  9.    return 0;
  10. }

Remember to compile using -std=c++0x in gcc.

(Thanks Hugo Arregui for correcting the POD example)

]]> http://nicolasb.com.ar/2011/04/cool-c0x-features-ii-variadic-templates-whats-wrong-with-varargs/feed/ 0