Nicolás Brailovsky

For open source projects, makefiles are a must. All C++ projects need them, even though cmake is strong nowadays, and even though Java has its own version (actually, several of them, but that’s not important now) a makefile could be used.

Even if it is an ubiquitous build system, it is pretty much outdated nowadays, and although using its basic features is easy, mastering it is a complex task. Worst still, mastering makefiles means you’ll probably produce write-only-code, and as makefiles are code themselves, and must therefore be maintained, this can be a nuisance to a newcomer to your project.

There’s an upside to makefiles being code: they can be reused. Once you find a configuration that suits your development process, you don’t need to write it again. I’ll post here some of the main targets I ussually include in a common.mk. As I mentioned, it’s mostly write-only-code, yet you may find it useful:

How is this used? Well, don’t even try to understand the dependency autogeneration, it’ll make your head explode.

This defines a rule for building .o objects; a variable named OBJECTS should be present when including this file.

A special rule is defined for a main object (actually this is needed to compile the tests, which we’ll do next time, since you may have a different main function).

And finally, a rule for to create the real binary. Next time I’ll add some cool features for TDD to this makefile.

Check this out:

What does this do? Does it compile? Does it crash? I’ll give you a second.

Ready? It does compile, OK
But it doesn’t crash.
Why, you may ask
Think about it, you must.

The compiler will mangle S::f and translate this into something like:

Now, in this new “translated” code, what do you think? Will it crash? It won’t, since no one is going to dereference “this”. Crazy, huh? This crazy idiom also allows even crazier things, like C++ objects committing sepuku

Long time without updates. I guess I needed vacations from the blog. It was not the first time and it probably won’t be the last one I take, but I’m back now with another truckload of C++ ramblings and misc stuff. Like this one:

It’s been a long time since I used the metapost category. I’ve been taking a look at the queries received by Google for which this blogs shows up. Some of them are quite peculiar, some of them may give us an insight of what the search engine things of me. For example:

There was a long list of variations to these phrases, but I didn’t want such a long post. Anyway, if you thought that grumpy is all Google considers me to be, brace yourself for a surprise:

Basically, a computer using trained-troll monkey, with no life. Pretty accurate, some people may say.

Literally signal of death in Spanish. Tip: Lack of pulse.

Another common search:

I guess those searches have a very low returning rate.

This is a query which sincerely surprised me:

I’ll do a public service here: it’s written ‘elephant’, buddy.

Have you ever wondered what’s the best way of having a class from which you can’t inherit, say, like Java’s final? Without any doubt, the best way is having a team capable of not doing things like inheriting from ‘class NeverEverEverInheritFromThis’. The second best way involves some magic and lots of beer: class Final {     protected:     Final() {} };

So, what the hell does that evil device do? Easy, it defines a protected constructor, meaning only derived classes will be able to access it (i.e. no public construction of this object). How does this stop other classes from inheriting? It doesn’t, unless we add one more keyword:

The virtual inheritance is meant to be used to avoid the dreaded diamond in multiple inheritance designs. It does a lot of magic with the constructors and the memory layout of the object; amongst other things, it’ll make any class which derives from X have only a single base class for Final and it’ll also make this hypothetical class call Final’s constructor without going through X first.

A complete explanation of virtual inheritance is beyond the scope of this article, but it’s enough for our Final device to know that it forces the virtual base’s constructors to be called first, thus now we can write this:

Try it and watch it fail!

Update 2011-07-08: Amazing how time flies. This article has been written about a year before its publishing, and, believe it or not, it’s already showing its age. What I would update on this article is the first paragraph: the best way of not having a problem with final classes is creating a design which doesn’t have artificial restrictions to the growth and extensibility of the system (i.e: don’t use final classes, they are usually a bad idea). I like that idea, I may write another article about it.

The linker is a magical beast which does all sort of crazy stuff with your binaries, without you even knowing it. Every Linux install has a linker living in the shadows, though seeing it in action is a rare supernatural event. There is an ancient tradition to communicate with the spirit of your linker. Not many know about this secret dark path and it’s powers to annoy even the most experienced (L)user.

You may begin your journey with the following enchanting:

If everything went fine nothing will seem to happen, yet if the gods of the console have heard you, the next time you try to run any binary at all you’ll start to see the real magic. Try it, a simple “ls” will do the trick (don’t use commands which are not binaries, like echo or export, these are “hardcoded” in bash, so to speak, and won’t work since no runtime linking is necessary: they have already been linked when bash started!).

Read the help you just found. There is a lot of useful information there. Knowing the libs will give you an insight on the dependencies and the loading process of a binary. I have no idea what would be the use of knowing the files for each lib. The symbols and bindings are quite interesting, they remind me of an strace.

“all” is probably the best option to annoy a fellow programmer. Just set the env var and watch him go crazy.

After creating a wrapper object on the last entries, we were left with three syntax changes two analyze:

• -> (delayed declaration)
• decltype
• auto

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:

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:

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:

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:

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:

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.

When all you have is ssh access to a machine you have enough to mount a remote disk to your work station. How? easy:

Remember you need permission for both local and remote directories.

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):

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:

Even though I have vim a Vim fan for a long time there still is a lot of stuff which amazes me about this little editor,  and this thing I last learned about it is in the “ZOMG that’s so cool I’m about to pee my pants” category. Unfortunately, if I were to draw a Venn diagram of the people who may find it cool I’d have to intersect the group of people reading my blog (yes, very small) with the group of people who like Vim and Monty Python. So, here’s to the null group:

Type :Ni! in Vim and be amazed, it’ll reply back: Do you demand a shrubbery?

Just how cool is that?