Nicolás Brailovsky » C++ http://nicolasb.com.ar A modern blog Tue, 07 Sep 2010 10:07:33 +0000 http://wordpress.org/?v=2.9.1 en hourly 1 C++ linking WTF http://nicolasb.com.ar/2010/09/c-linking-wtf/ http://nicolasb.com.ar/2010/09/c-linking-wtf/#comments Tue, 07 Sep 2010 10:07:33 +0000 nico http://nicolasb.com.ar/?p=972 It is a commonly accepted fact that a succesfuly compiled application serves as enough proof of its correctness, but common wisdom doesn’t say a thing about linking. If you like linker WTF moments, you’ll love this snippet. Can you guess why won’t it compile?

  1. struct Foo {
  2.     static const int x = 0;
  3.     static const int y = 1;
  4.  
  5.     int z(bool x){
  6.         return (x)? Foo::x : Foo::y;
  7.     }
  8. };
  9.  
  10. #include
  11. int main() {
  12.     Foo z;
  13.     std::cout << z.z(true);
  14.     return 0;
  15. }
  16.  

Well, it does compile (gotcha!) but it just won’t link. Yet it seems so simple… let’s add some more mistery to this WTF moment, try this change:

  1.    int z(bool x){
  2.         int t = Foo::x;
  3.         return (x)? t : Foo::y;
  4.     }
  5.  

Holy shit, now it compiles? WTF? Some more strangeness:

  1.    int z(bool){
  2.         return (true)? Foo::x : Foo::y;
  3.     }
  4.  

And again, now it compiles. WTF? I’ll make a final change, this one should give you a clue about why it won’t compile. Revert all changes back to the original code but add this two lines after Foo:

  1.  
  2. const int Foo::x;
  3. const int Foo::y;
  4.  

Though weird at first, now you should have a clear picture:

  • The first case doesn’t compiles: x and y are declared in struct Foo, yet the linker doesn’t know in which translation unit they should be allocated.
  • The second and third cases… well I’m not sure why does this compiles but it’s probably because the linker can asume in which translation unit x and y should be allocated. I’m to lazy to check.
  • In the last case we explicitly say where should x and y be. According to standard, this is how these two ints should be declared.

So, some linker strangeness. Beware, it’s easy to get trapped by this one.

]]> http://nicolasb.com.ar/2010/09/c-linking-wtf/feed/ 0 Template Metaprogramming XIII: Heart of Darkness http://nicolasb.com.ar/2010/08/template-metaprogramming-xiii-heart-of-darkness/ http://nicolasb.com.ar/2010/08/template-metaprogramming-xiii-heart-of-darkness/#comments Tue, 31 Aug 2010 10:00:57 +0000 nico http://nicolasb.com.ar/?p=1222 Last time we had a virtual template dispatch problem… we got to the point of knowing which was the index of the cache we were searching for, now we need to actually retrieve an instance of that cache. That’s a problem. Why? To begin with, there are no instances, only types!

The next logical step would be to create a Map device, to map a list of types to a list of instances… let’s see how can we do that, in pseudocode

  1. instances( H|T ) <- [ create_instance(H), instances(T) ]
  2. instances( NIL ) <- NIL

Looks easy. How can we map that to c++?

  1. template <class Lst> struct Instance {
  2.     typedef typename Lst::head Elm;
  3.     Elm instance;
  4.     Instance< typename Lst::tail > next;
  5. };
  6. template <> struct Instance<NIL> {};
  7.  
  8. #include <iostream>
  9. using std::cout;
  10.  
  11. int main() {
  12.     typedef LST<int, LST<char, LST<float> > > Lst;
  13.     Instance<Lst> lst;
  14.     lst.instance = 1;
  15.     lst.next.instance = ‘a’;
  16.     lst.next.next.instance = 3.1;
  17.     std::cout << lst.next.instance << "\n";
  18.     return 0;
  19. }

All those next.next.next.instance look ugly. Let’s use some more meta-magic to get the Nth instance (why not a [] operator? several reasons, you can’t mix non-const ints with templates nicely, there would be problems to define the return type… all those options are workable but it’s easier if we do this in another device.

  1. template  struct Nth {
  2.         typedef typename LST::tail Tail;
  3.         typedef typename Nth::result result;
  4. };
  5. template  struct Nth {
  6.         typedef typename LST::head result;
  7. };

Remember that one from the toolbox? Now we know how to get a specific index position, yet getting the instance is a different problem (the Nth device returns a type, not an instance). We should do something different, the problem is knowing the return type. What’s the return type for the Nth instance of the Instances list?

  1.  
  2.    type <- Nth(TypesLst, Type)
  3.    type var <- NthInstance(InstancesLst, N)
  4.  

Not so easy, right? This is the translated C++:

  1.  
  2. template <class TypeLst, int N> struct NthInstance {
  3.     // This one isnt easy…
  4.    
  5.     // This is the next type in the list
  6.     typedef typename TypeLst::tail TypeNext;
  7.     //  * Nth::result is the Nth type in Lst (i.e. char, int, …)
  8.     typedef typename NthInstance< TypeNext, N-1 >::NthInstanceType NthInstanceType;
  9.     //  * typename Nth::result &amp; is a reference to said type and the ret type
  10.     template <class InstancesLst>
  11.     static NthInstanceType& get(InstancesLst &instances_lst) {
  12.         return NthInstance< TypeNext, N-1 >::get(instances_lst.next);
  13.     }
  14. };
  15.  
  16. // Remember we chose a 1-based system (wtf..)
  17. template <class TypeLst> struct NthInstance<TypeLst, 1> {
  18.     typedef typename TypeLst::head NthInstanceType;
  19.  
  20.     template <class InstancesLst>
  21.     static NthInstanceType& get(InstancesLst &instances_lst) {
  22.         return instances_lst.instance;
  23.     }
  24. };
  25.  

And the code from fetching the instance itself is even more difficult, so I’ll leave that for next time.

]]> http://nicolasb.com.ar/2010/08/template-metaprogramming-xiii-heart-of-darkness/feed/ 0 Template Metaprogramming XII: You Really Got a Hold on Me http://nicolasb.com.ar/2010/08/template-metaprogramming-xii-you-really-got-a-hold-on-me/ http://nicolasb.com.ar/2010/08/template-metaprogramming-xii-you-really-got-a-hold-on-me/#comments Tue, 24 Aug 2010 10:00:42 +0000 nico http://nicolasb.com.ar/?p=1219 Remember our virtual template method problem, from the other time? (I know, I said the answer was scheduled for a week after that post, but then I just forgot about it). May be we could avoid the virtual part by keeping a list of all our caches… how would we know which one should we dispatch the message to? Easy, using templates.

Instead of a list let’s keep two, for twice the fun. One for the rows cache, another for the PKs. We can use PK to know which ROW Cache should we choose. Let’s try to write a pseudo code for it:

  1. ROW get_row(PK id) {
  2.     pos <- Position of PK in pks_lst
  3.     return cache[ pos ].get_row( id )
  4. }
  5.  

Doesn’t look too hard. Building on our previous toolbox, let’s use Eq, Position and the definition of a list:

  1. struct NIL {
  2.     typedef NIL head;
  3.     typedef NIL tail;
  4. };
  5.  
  6. template < class H, class T=NIL> struct LST {
  7.     typedef H head;
  8.     typedef T tail;
  9. };
  10.  
  11. template <class X, class Y> struct Eq { static const bool result = false; };
  12. template <class X> struct Eq<X, X> { static const bool result = true; };
  13.  
  14. template <class Elm, class LST> struct Position {
  15.     private:
  16.     typedef typename LST::head H;
  17.     typedef typename LST::tail T;
  18.     static const bool found = Eq<H, Elm>::result;
  19.     public:
  20.     static const int result = found? 1 : 1 + Position<Elm, T>::result;
  21. };
  22.  
  23. template <class Elm> struct Position<Elm, NIL> {
  24.     static const int result = 0;
  25. };
  26.  
  27. class Facade {
  28.     typedef LST<int, LST<char, LST<float> > > Lst;
  29.  
  30.     public:
  31.     template <class PK> int find(PK) {
  32.         return Position< PK, Lst >::result;
  33.     }
  34. };
  35.  
  36. #include <iostream>
  37. using std::cout;
  38.  
  39. int main() {
  40.     Facade f;
  41.     std::cout << f.find(1.0) << "\n";
  42.     return 0;
  43. }
  44.  

Great, now we can find an element on a list of types. The real virtual dispatch for the next entry :D

]]> http://nicolasb.com.ar/2010/08/template-metaprogramming-xii-you-really-got-a-hold-on-me/feed/ 0 C++ Namespaces and g++ http://nicolasb.com.ar/2010/08/c-namespaces-and-g/ http://nicolasb.com.ar/2010/08/c-namespaces-and-g/#comments Tue, 03 Aug 2010 12:48:32 +0000 nico http://nicolasb.com.ar/?p=699 Have you ever tried to leave open a C++ namespace after EOF (that is, openning a namespace in a headerfile but forgetting to close it). It’s a little bit like getting your balls caught by the door. The compiler will throw at you an incredible number of seemingly unrelated errors, all of which occur in a different file than the offending header.

Reaching EOF on a C++ file without closing all its namespaces should be ilegal; or at least you should have better error reporting, because right now it’s almost impossible to know what’s the source of the error (for g++, that is). ]]> http://nicolasb.com.ar/2010/08/c-namespaces-and-g/feed/ 0 Design Patterns: C++ Idiom RAII http://nicolasb.com.ar/2010/07/design-patterns-c-idiom-raii/ http://nicolasb.com.ar/2010/07/design-patterns-c-idiom-raii/#comments Tue, 27 Jul 2010 10:00:37 +0000 nico http://nicolasb.com.ar/?p=427 Ohh design patterns. I love buzzwords. Who doesn’t? To increase my buzzword count I will be writing about a topic most people programming C++ should already know: RAII, resource acquisition is initialization.

Patterns everywhere

Knowing that Gamma et al didn’t list all the known patterns in the universe does come as a surprise to some, not sure why though. The twenty some patterns they write about in their now famous book are (arguably, perhaps) some of the most common design patterns, but the list hardly finishes there.

Some patterns only have meaning in a very specific context; a reactor is a nice pattern for handling asynchronous events yet most applications would never need it. Sometimes “the context” means a specific domain in which the application must work, like a web application, a real time application or a distributed application, sometimes the context is the language itself. RAII falls in this last domain, it only makes sense for C++ applications (actually there are others, but thinking what kind of languages would support this idiom is left as an exercise for the reader).

No, really. What is RAII?

If you made it past that long intro you are probably really interested in knowing what RAII is, and don’t know how to search it in Wikipedia. OK, I’ll explain it the best I can then: RAII means that a resource acquisition is the initialization.

Seriously. That is all the secret there is to RAII. Talking in code:

  1. template
  2. class RAII_Wrapper {
  3.    T *resource;
  4.  
  5.    public:
  6.       RAII_Wrapper (T *resource)
  7.             : resource(resource)
  8.       {
  9.          resource->open();
  10.       }
  11.  
  12.       ~RAII_Wrapper ()
  13.       {
  14.          resource->close();
  15.       }
  16. };

An example

Compare that to a visitor pattern. It’s just too simple to be of any use, isn’t it? Well, contrary to what Java fanboys tend to believe you can do lots of nice things without writing a bazillion lines of code.

  1. int foo() {
  2.         Expensive_Resource x;
  3.         x.open();
  4.  
  5.         try {
  6.                 if (not bar()) {
  7.                         x.close();
  8.                         return -1;
  9.                 }
  10.         } catch (…) {
  11.                 x.close();
  12.                 throw "up";
  13.         }
  14.  
  15.         int ret;
  16.         try {
  17.                 ret = baz();
  18.         }catch(…) {
  19.                 // We don’t care, we’re closing x anyway
  20.         }
  21.  
  22.         x.close();
  23.         return ret;
  24. }

Wow… a whole lot of code just for calling bar and baz. And as I wrote that without even compiling I’m sure there are too many hidden bugs, lots of code-paths my simple programmer’s mind can’t even begin to imagine which will cause my Expensive_Resource to be leaked!

Let’s rewrite that using RAII:

  1. void foo() {
  2.         Expensive_Resource x;
  3.         RAII_Wrapper release(&amp;x);
  4.  
  5.         if (not bar()) return -1;
  6.         return baz();
  7. }

A lot nicer, isn’t it? But, what happened to all the try/catch if’s and closes there?

Where’s the magic?

The magic of RAII lies in how C++ handles exceptions. When we have a built object (can an object be in an unbuilt state?) it means it’s constructor has correctly ran. It also means it’s destructor will run when it goes out of scope, doesn’t mater HOW it goes out of scope.

See how brilant that is? Doesn’t matter if a function we’re calling throws, or if we need to return before reaching the end of the function: the destructor will be called and thus our Expensive_Resource will be free!

Why is this C++ specific?

This is an easy one: think how would you implement this in Java: right, you can’t. Not knowing when is your object going to be destroyed means you can’t do anything useful in its destructor, therefore RAII is deeply rooted within the memory management in C++ and it’s pretty much a language specific pattern (or is it?). But, is that so good?

Not everything is so great…

You are probably thinking this is the best discovery since ice cream was invented. Well, not so fast, RAII has it’s detractors too.

The first problem in RAII, it doesn’t have a graceful way of handling resource acquisition failure. If Expensive_Resource is a database, and it’s connection fails, we have a throwing constructor.

Even if throwing constructors are acceptable, throwing destructors may even be a worst idea: throwing while an exception is already active is a cause for concern (tip: it’ll crash your application, doesn’t matter how many try/catch blocks you use, due to stack unwinding issues).

And then, even if we don’t care about throwing destructors you have the issue of a release failure: how do you notify the user that a release failure has occurred? And what do you do, should it happen?

So, RAII is a great idea indeed, and it has it’s uses, but you should be careful when choosing this C++ specific pattern.

]]> http://nicolasb.com.ar/2010/07/design-patterns-c-idiom-raii/feed/ 0 Template metaprogramming XI: Hidden Agenda http://nicolasb.com.ar/2010/07/template-metaprogramming-xi-hidden-agenda/ http://nicolasb.com.ar/2010/07/template-metaprogramming-xi-hidden-agenda/#comments Tue, 20 Jul 2010 10:00:03 +0000 nico http://nicolasb.com.ar/?p=918 Wow, number eleven already. We’re getting more chapters here than Final Fantasy games. I didn’t even imagine there was so much to write about such an esoteric language features like templates. I do wonder if anyone will actually read it, but that’s a completly different problem.

Enough meta-meta talk: what can we do with all the things we have learned? We can calculate pi and e, we already showed that as an example on one of the first chapters. This chapter I’m going to write about what motivated me to explore the bizarre underworld of template metaprogramming. Some time ago I had to work with a Berkeley DB researching the feasibility of developing a magic cache for (real) DB table. Leaving aside the discussion of whether this is a good idea (the project did have a good reason to be researched) I hit a major roadblock when trying to provide a façde for every table; something like this: See the problem? To do something like that we’d need a virtual template method, and you can’t have that. After seeing that I thought to myself “Hey, I’ll use templates!”. Then I had two problems, but the damage was done, I couldn’t go back. What kind of contorted device could we implement to make such a devious requirement work? I’ll leave you to think it, the answers I came up with next week.

]]> http://nicolasb.com.ar/2010/07/template-metaprogramming-xi-hidden-agenda/feed/ 0 C++ pretty functions http://nicolasb.com.ar/2010/06/c-pretty-functions/ http://nicolasb.com.ar/2010/06/c-pretty-functions/#comments Tue, 22 Jun 2010 10:00:12 +0000 nico http://nicolasb.com.ar/?p=428 There are two well known macros from the preprocessor which every macro-sorcer must know. They are __FILE__ and __LINE__. You probably already know about them but anyway, __FILE__ will give you the current file and __LINE__ the current line. Easy, huh?

  1. int main() {
  2.    printf("%s : %i", __FILE__, __LINE__);
  3.    return 0;
  4. }
 gccegg-65

The program above would give you “main.cpp : 3″ as a result. There is nothing going on at execution time, it’s all preprocesor wizardy. In fact with “g{++/cc} -E” you can even check what the “real” output is (-E means to return the preprocessor output. Keep in mind a lot of stuff will be included from the headers you use).

  1. int main() {
  2.    printf("%s : %i", "main.cpp", 3);
  3.    return 0;
  4. }

Well that’s nice and all, but g++ can top this easily:

  1. int main() {
  2.    std::cout << __PRETTY_FUNCTION__ << "\n";
  3.    return 0;
  4. }

There are a couple of notable things about this new “pretty function” thing:

  • 1. It will demangle a function’s name
  • 2. This time it isn’t a preprocessor secret thing but a real variable g++ will create.

You can easily use this for better logging functions now (with some macro wizardy, obviously).

]]> http://nicolasb.com.ar/2010/06/c-pretty-functions/feed/ 0 Template metaprogramming X: Zero Minus Ten http://nicolasb.com.ar/2010/06/template-metaprogramming-x-zero-minus-ten/ http://nicolasb.com.ar/2010/06/template-metaprogramming-x-zero-minus-ten/#comments Thu, 17 Jun 2010 10:00:24 +0000 nico http://nicolasb.com.ar/?p=914 So far we’ve learned the basic constructs of template metaprogramming (loops, branching, return values) and some basic list operations (getting the length of a list, appending and preppending elements, checking if an element is included in a list). Let’s put it all together by creating an operation to return the position of an element. It’ll be very useful later on too.

If we go back to the Includes operation we can get some help to define the Position operation: the position of an element in a list is one plus the position of the element we’re searching for in the tail, or zero if the head equals said element. The operation is not defined if the element is not in the list.

Translating to pseudo-code:

  1. Position (lst.head, lst) <- 0
  2. Position (e, lst) <- 1 + Position(e, lst.tail)

The translation to C++ is not so trivial this time. Try it, I’ll wait… ready? OK, let’s start

  1. template <class Elm, class Lst> struct Position {
  2.         typedef typename Lst::head Head;
  3.         typedef typename Lst::tail Tail;
  4.         static const bool found = (Head == Elm);
  5.         static const int result = found? 0 : 1 + next;
  6.         static const int next = Position<Elm, Tail>::result;
  7. };

Looks easy… but doesn’t work. First problem, we can’t compare two types, remember? We need to use Eq<X, Y> again. Second problem, although we said the operation is undefined if the element is not included on the list, it would be nice if we could force the compiler to fail if (or when) that happens. Let’s rewrite the operation using a façade again, but adding an Assert:

  1. template <typename Elm, typename LST> struct _Position {
  2.         typedef typename LST::head Head;
  3.         typedef typename LST::tail Tail;
  4.  
  5.         static const bool found = Eq<Elm, Head>::result;
  6.         static const int result = (found)? 0 : 1 + _Position<Elm, Tail>::result;
  7. };
  8.  
  9. template <typename Elm, typename LST> struct Position {
  10.         typedef typename Assert<Includes< Elm, LST >::result>::check include;
  11.         static const int result = _Position<Elm, LST>::result;
  12. };

Oh, we haven’t defined assert yet! There’s another problem, too: even if it won’t compile, the compiler will try to expand _Position< …, NIL > indefinately, causing an error after too many nested template calls. Not nice. We need to add a case to make the compiler stop:

  1. /******************************************************/
  2.  
  3. // Helper: Will fail to compile if the assert is false
  4. class Assertion{};
  5. template <bool cond, class T=Assertion> struct Assert {
  6.         typedef typename T::fail check;
  7. };
  8. template <> struct Assert<true> {
  9.         typedef void check;
  10. };
  11.  
  12. /******************************************************/
  13.  
  14. template <typename Elm, typename LST> struct _Position {
  15.         typedef typename LST::head Head;
  16.         typedef typename LST::tail Tail;
  17.  
  18.         static const bool found = Eq<Elm, Head>::result;
  19.         static const int result = (found)? 0 : 1 + _Position<Elm, Tail>::result;
  20. };
  21.  
  22. // The compiler will try to expand the position check
  23. // after NIL has been reached if this isn’t here
  24. template <typename Elm> struct _Position<Elm, NIL> {
  25.         static const int result = 0;
  26. };
  27.  
  28. template <typename Elm, typename LST> struct Position {
  29.         typedef typename Assert<Includes< Elm, LST >::result>::check include;
  30.         static const int result = _Position<Elm, LST>::result;
  31. };

All that code for such a simple operation, man. Also, see what we did with Assert<>? It seems making a compile fail is actually quite easy. That’s what I have most experience with.

We’ve been through quite a lot, and our toolboox should be quite big already. Next time we’ll start steering towards some sort of aplicability, trying to use some of all these stuff to implement a real, useful and working program… assuming that’s even posible.

]]> http://nicolasb.com.ar/2010/06/template-metaprogramming-x-zero-minus-ten/feed/ 0 Template metaprogramming IX: Absolute Zero http://nicolasb.com.ar/2010/06/template-metaprogramming-ix-absolute-zero/ http://nicolasb.com.ar/2010/06/template-metaprogramming-ix-absolute-zero/#comments Thu, 10 Jun 2010 10:00:59 +0000 nico http://nicolasb.com.ar/?p=908 By now we should have learned how to perform loops, branching and returns using templates. Let’s add a couple of useful operations to our library: append and prepend.

Prepending an element to a list is very easy: the result is a list (oh surprise) consisting of a head (the element we want to add) and a tail (the old list). In the pseudocode I’ve been using so far:

  1. Prepend(e, lst) <- LST(e, lst)

And in C++ (trivial, this time):

  1. template <typename Elm, typename Lst=NIL> struct Preppend {
  2.         typedef LST<Elm, Lst> result;
  3. };

Appending is a little bit more difficult, as we need to first find the end of the list. Think for a second how would you define it… back? Ok, I’d define it this way: appending an element to the list yields a list, consisting of the same head and the result of appending said element to the tail. The null case, as usual, is appending an element to a NIL list; in this case the result is a list with the element itself. So:

  1. Append(e, NIL) <- LST(e)
  2. Append(e, lst) <- LST(lst.head, Append(e, lst.tail))

Looks complicated what it follows the same structure as the rest of the basic-ops:

  1. template <class Elm, class Lst> struct Append {
  2.         typedef typename Lst::head Head;
  3.         typedef typename Lst::tail Tail;
  4.  
  5.         typedef typename Append<Elm, Tail>::result Next;
  6.         typedef typename LST<Head, Next>::result result;
  7. };
  8.  
  9. template <class Elm> struct Append<Elm, NIL> {
  10.         typedef LST<Elm> result;
  11. };

Easy. Now, what happens if we want to add a default value for Lst, so we can use Append to create lists? Easy too, but we need a façade this time; just rename Append to _Append, then

  1. // This is here just because I wanted a default param :D
  2. template <typename Elm, typename Lst=NIL> struct Append {
  3.         typedef typename _Append<Elm, Lst>::result result;
  4. };

I promised to add one more operation to our toolbox, returning the position of an element, but this post is getting quite long and I’m afraid it may be too much for the average attention span of a programmer… we’ll leave it for next time.

]]> http://nicolasb.com.ar/2010/06/template-metaprogramming-ix-absolute-zero/feed/ 0 Template metaprogramming VIII: A Rough Whimper of Insanity http://nicolasb.com.ar/2010/06/template-metaprogramming-viii-a-rough-whimper-of-insanity/ http://nicolasb.com.ar/2010/06/template-metaprogramming-viii-a-rough-whimper-of-insanity/#comments Thu, 03 Jun 2010 10:00:03 +0000 nico http://nicolasb.com.ar/?p=902 Remember last time? We learned how to get the lenght of a list. This time I’ll introduce some more of these basic ops. Let’s begin with “Nth”: getting the Nth element of a list; which, remember, in this case is a type, not a concrete element. This means the Nth element will be something like int, char, const char*, not 1, 2 or 3. We introduced a trick to get around this limitation before using a template <int>, go there to refresh your memory if needed.

So, what would the coloquial definition of “Nth” be? I’d put it like “The operation Nth for a list equals the head of the list for N = 0 and Nth (minus one) of tha tail otherwise”. A little bit more formally:

  1. Nth(0, lst) <- lst.head
  2. Nth(n, lst) <- Nth(n-1, lst.tail)

Translating this to C++ should be a breeze to you now. Try it, I’ll wait. Read? OK, this is MY answer:

  1. template <typename LST, int N> struct Nth {
  2.         typedef typename LST::Tail Tail;
  3.         typedef typename Nth<Tail, N-1>::result result;
  4. };
  5.  
  6. template <typename LST> struct Nth<LST, 0> {
  7.         typedef typename LST::head result;
  8. };

Though the structure is very similar to the previous “basic operation”, getting the length of a list, the concept is quite different. This time we’re defining a return type recursivly. Anyway, it was too easy indeed, let’s try a more complex operation now.

How can we check if an element exists on a list? Seems easy enough, an element is included in a list if the head equals the element itself or if the element is included in the tail. In the pseudo language I just invented:

  1. Includes(lst.head, lst) <- true
  2. Includes(e, lst) <- Includes(e, lst.tail)

Looks easy, right? Well, there’s a bug there, can you spot it? Yeah, we’re missing the false condition. We should add a third spetialization:

  1. Includes(lst.head, lst) <- true
  2. Includes(e, NIL) <- false
  3. Includes(e, lst) <- Includes(e, lst.tail)

Again, let’s translate the pseudocode to C++. Try it, I’ll wait. Read? OK, this is MY answer:

  1. template <class Elm, class Lst> struct Includes {
  2.         typedef typename LST::head Head;
  3.         typedef typename LST::tail Tail;
  4.  
  5.         static const bool found = (Elm == Head);
  6.         static const bool found_tail = Includes<Elm, Tail>::result;
  7.         static const bool result = found || found_tail;
  8. };
  9.  
  10. template <class Elm> struct Includes <Elm, NIL> {
  11.         static const bool result = false;
  12. };

Looks nice, doesn’t it? Too bad it won’t work, you can’t compare two types. What would (int == char) mean in C++? We need a helper there, some kind of trick to compare to types. We can use partial template spetialization again:

  1. template <class X, class Y> struct Eq { static const bool result = false; }
  2. template <class X> struct Eq<X, X> { static const bool result = true; }

With this little struct now we can write our include operation this way:

  1. template <class Elm, class Lst> struct Includes {
  2.         static const bool result =
  3.                                 Eq<Elm, typename LST::head>::result
  4.                                  || Includes<Elm, typename LST::tail>::result;
  5. };
  6.  
  7. template <class Elm> struct Includes<Elm, NIL> {
  8.         static const bool result = false;
  9. };

Very esoteric looking, the right mix of Haskel, C++ and booze to ensure job security for life. Next time we’ll find a way to search for the position of an element, a somewhat more complicated task.

]]> http://nicolasb.com.ar/2010/06/template-metaprogramming-viii-a-rough-whimper-of-insanity/feed/ 0