Mailund on the Internet

One of our PhD students had problems with C++ today and asked me for help.

He had a piece of code that, for this post, can be reduced to this:

#include <vector>

template <typename T>
class C {
    void foo(std::vector<t>::iterator i);
};

If you are an experienced C++ programmer, it doesn’t take you long to see the problem here, but if you are not, this piece of code looks perfectly valid and the error message you get from g++

test.cc:6: error: ‘class std::vector<T, std::allocator<_CharT> >::iterator’ is not a type
test.cc:7: error: expected unqualified-id at end of input

is of no help at all.

Why isn’t vector<T>::iterator a type? It always is!

Well, the thing is, that is not actually guaranteed.

Another example that shows the problem might make it clearer.

template <typename T>
struct C {
    int p; 

    void foo()
    {
	T::t * p;
    }
};

In foo, are we defining p as a pointer to a T::t, or are we just multiplying a static member T::t with the instance variable p?

You cannot know that before you know T, and to get around that problem, the C++ standard requires that you make types explicit using the typename keyword.  If you don’t, it will assume that you mean a static member.  So you should change the example to this:

template <typename T>
struct C {
    int p; 

    void foo()
    {
	typename T::t * p;
    }
};

What about the vector example, then?  Surely a vector<T>::iterator is always a type?

No, actually not.  You can always specialize a template like vector<T> and for example say that a vector of class C has a static member named iterator, instead of a typedef.

Think about vector<bool>.  That is a specialization, and is different from what the generic vector<T> would be, if it had been instantiated with T=bool.

Until the point where a template is instantiated, you really know very little about it, so you need to help the compiler.

The fix to the original problem is just adding the typename keyword:

#include <vector>

template <typename T>
class C {
    void foo(typename std::vector<t>::iterator i);
};

–

20-36=-16

I must have tried every single plugin for source code highlighting, and none of them can handle templates in C++!

Well, one of them could, the google syntax highlighter could, but the image it creates is uglier than ugly.

This is really pissing me off.  How hard can it be not to fuck up < and >? Or if you want to consider them tags, then not to fuck up &lt; and &gt;?

I’m giving up now and sticking to good old <pre>…</pre>.  It isn’t pretty, but at least it shows the code I want to show, not some mangled piece of crap!

–

20-35=-15

I used the Guile (Scheme) language as both a configuration language and embedded script language in a number of applications I wrote several years ago (e.g. GeneRecon and CoaSim).

I’m a firm believer in adding extension languages to programs.  As soon as a program is too complex to be run as a simple shell command (without too many command-line options) it needs at least a configuration file, and once you add that, the configuration options will start to get more and more complicated.

You don’t want to write your own parser for such a configuration file. Ad hoc solutions will give you an awful format — just think of sendmail — and it really isn’t worth the effort.  A much better solution is to use an existing programming language and just embed it in your program.

That was the idea behind Guile.  The inspiration was Emacs with its Lisp configuration and extension language.  Guile is a Scheme interpreter and is designed to be easy to embed in your own programs.

To use it, you write a few handles into your application that can be called from Guile, then in your main program you initiate an interpreter, read the configuration file and let the interpreter evaluate it, and viola you have added a lot of flexibility to how your program can be configured.

For even more flexibility, you can read Scheme code interactively while your application runs, or you can define hooks in your configuration script that can be called by the application to customise it.  I use both in CoaSim to get maximal flexibility in my simulator.

I don’t use Guile any more. These days, I use Python for my extension language. Well, actually it is usually the other way around: I let Python be in charge and build packages that extends Python.  I find Python easier to work with for most applications than I find Scheme, and there is no doubt that Python is much better known in the bioinformatics field than Scheme is.

Still, I fondly remember Guile.  If you are interested in a little history lesson, check out A Brief History of Guile.

–

20-34=-14