Throwing destructors

We already know what happens when you throw from a constructor. Ending up with a half built object is not good, but suppose we do manage to build one correctly. What happens if we throw in a destructor instead? The results are usually much worse, with a very real possibility of having your program terminated. Read on for a brief explanation on the perils of throwing constructors.

So, according to RAII pattern, resource deallocation should occur during the destructor, yet resource freeing is not exempt of possible errors. How would you notify of an error condition?

• First error handling choice, you notify /dev/null of the error condition. Best case, you may log the error somewhere, but you can't do anything about it, you end up ignoring it. Not good, usually you'll want to do something about the error condition, even more if it's transient.
• Second choice, throw. The user (of the class) will know something has gone horribly wrong. This option seems better, yet it has some disadvantages too (just as it happened with throwing destructors; when is an object completely deleted? is it ever deleted if an exception is thrown whilst running?)

Yet the worst part is not resource leaking through half destroyed objects, the worst part is having your program call std::abort.

Think of it this way: when an exception is active, the stack is unwind, i.e. the call stack is traversed backwards until a function which can handle the exception is found. And you just can't unwind the stack while unwinding the stack (you'd need a stack of stacks) so the reasonable thing to do is call std::abort.

So, what can you do about it? Go to your favorite jobs posting site and start searching for a PHP position, you'll sleep better at nights.

Zero padding for Bash scripts

Lately I found myself trying to generate a video from a series of images generated by a program. Doesn't sound difficult, until you start running into a stupid issue: your 1000th frame will come before your 2nd frame!

Luckily there's a very easy fix for this problem, just add zero padding in a bash script. How?

for i in `seq 1 10`; do echo $i; done

That will print all the numbers between 1 and 10. This one will do the same, with zero padding:

for i in `seq 1 10`; do printf "%02dn" $i; done

200th post!

Yes, this is the post number 200 on this blog. Considering we are a month away of starting the fourth year, I guess that gives me quite a lousy periodicity, but I am still surprised I post somewhat regularly here after such a long time (hey, in programmer years that's like a whole life!).

Since the beginning this blog has mutated from being  my public notepad to being a place where I research new topics, or write about things that are generally interesting to me. I lost many readers for posting crazy metaprogramming stuff and for constantly babbling about Vim and Linux, but hey, I'm proud of if. Let's see what the next 200 posts bring here.

Automagic document conversion for your makefiles

So, now you have a common makefile, ready to be used for a TDD project and for code coverage report automagic generation. Not only that, but it even speaks to endlessly annoy your team. What else can we add to this makefile? Well, automatic documentation generation, clearly.

You want to batch convert .doc to .pdf using the command line on a server without a GUI? Or you need automated .ppt to .swf conversion through cron, a sysvinit service, or a remote web server? Online conversion services such as Zamzar.com and Media-convert.com not working for you? Whichever formats you need to batch convert, PyODConverter is a simple Python script for just this purpose.

-- http://www.oooninja.com/2008/02/batch-command-line-file-conversion-with.html

Activating tildes and accents for a USA keyboard layout in Ubuntu

Wow. This time the title of the post may actually be longer than its contents. How do you enable accents and tildes in Ubuntu? You need it to type cool characters like á, Ó or ñ (hey, my name has one of these!).

If you are on Windows I think you have to install a new map, and then guess where the key would be. Or use an alt+something magic spell. In Ubuntu, it works by default you just need to add a compose key, Go to System > Preferences > Keyboard > Options > compose key position, select right alt (or whatever you fancy), there you go, now it works. Try it by typing alt + ' + a.

A talking makefile

So, after learning how to use makefiles, then how to use makefiles for TDD and for code coverage report, now you need to annoy your whole team with a talking makefile. What could be better to notify everyone on your team when a test fails than a synthesized voice commanding you to fix your program?

test: $(TEST_SRCS)
	@for TEST in $(TEST_BINS); do 
		make "$$TEST"; 
		echo "Execute $(TEST)"; 
		if ! ./$$TEST; then 
			echo "Oh noes! I detected a failed test from $$TEST. Go and fix your program!" | festival --tts ; 
	done

Try it. You'll love it.

Bonus chatter: when Valgrind detects over $MUCHOS errors it'll print "Too many errors detected. Go and fix your program", then it won't print so much detail in the next backtraces.

Edit pdf files in Ubuntu

Well, for some reason my LaTeX py-pygments stopped compiling. Thanks for breaking backwards compatibility, you pig-ments.

I had two options, either spend hours trying to fix this by altering the preamble, or just edit the pdf file. Yeah, I know, editing the pdf sounds ugly as hell, but hey at 2 am in the morning I'll take anything. And pdfedit was there to save the day (night). Just apt-get install pdfedit, it's in the repo.

A Makefile for code coverage report with C++

So far you should know how to use makefiles and you should have a nice testable project. Then you have everything ready to get a coverage report. Yeah, using makefiles, you guessed!

This time we'll depend on two tools, gcov and gtest. These are in Ubuntu's repositories, so you should have no problem getting them. I won't even bother to explain this makefile (not because it's obvious but because I don't really remember how it works. I wrote this over a year ago).

.PHONY: clean coverage_report
coverage_report:
	# Reset code coverage counters and clean up previous reports
	rm -rf coverage_report
	lcov --zerocounters --directory .
	$(MAKE) COMPILE_TYPE=code_coverage &&
	$(MAKE) COMPILE_TYPE=code_coverage test
	lcov --capture --directory $(BIN_DIR)/$(OBJ_DIR)/code_coverage --base-directory . -o salida.out &&
	lcov --remove salida.out "*usr/include*" -o salida.out &&
	genhtml -o coverage_report salida.out
	rm salida.out

Bonus makefile target: make your code pretty:

.PHONY: pretty
pretty:
	find -L|egrep '.(cpp|h|hh)$$'|egrep -v 'svn|_Test.cpp$$' | xargs astyle --options=none

Remember to change your astyle options as needed.

Bonus II: Example project using gcov and gtest: gcov_gtest_sample.tar. The irony? It doesn't use my common makefile, it predates it.

Link: ASCII graphs, 2.0 style

Every once in a while you need to draw a graph to quickly convey some information, and you don't want all the hassle of opening paint, drawing whatever you want, exporting it as png, and all that stuff. Sometimes it's just easier to do it as ASCII art, only you don't want to spend hours carefully aligning pipes and dashes. For these times Asciiflow exists.

Give it a try, it's a great way to quickly generate a diagram. Just remember to use monospace fonts.

A Makefile for TDD with C++

So, after reading my post about makefiles you decided that you like them but would like to add some TDD to be buzzword compliant? No problem, that's easy to do.

Assuming you use a naming convention such as this one:

path/to/src/Object.h
path/to/src/Object.cpp
path/to/src/Object_Test.cpp

then it's easy to auto detect which tests should be built:

TEST_SRCS := $(patsubst ./%, %, $(shell find -L|grep -v svn|egrep "_Test.cpp$$" ) )
TEST_BINS := $(addprefix ./$(BIN_DIR)/, $(patsubst %.cpp, %, $(TEST_SRCS)) )

Then we have to define a special rule with pattern matching to compile the tests:

$(BIN_DIR)/%_Test: $(patsubst $(BIN_DIR)/%, %, %_Test.cpp ) %.cpp %.h
	@echo "Making $@"
	@mkdir -p $(shell dirname $@)
	g++ $(CXXFLAGS) -g3 -O0 $< -o $@ -lpthread -lgtest_main -lgmock $(OBJECTS) $(LDFLAGS)

and some magic to auto execute every test when we "make test":

test: $(TEST_SRCS)
	@for TEST in $(TEST_BINS); do 
		make "$$TEST"; 
		echo "Execute $(TEST)"; 
		./$$TEST; 
	done

Everything nice and tidy for a copy & paste session:

TEST_SRCS := $(patsubst ./%, %, $(shell find -L|grep -v svn|egrep "_Test.cpp$$" ) )
TEST_BINS := $(addprefix ./$(BIN_DIR)/, $(patsubst %.cpp, %, $(TEST_SRCS)) )

$(BIN_DIR)/%_Test: $(patsubst $(BIN_DIR)/%, %, %_Test.cpp ) %.cpp %.h
	@echo "Making $@"
	@mkdir -p $(shell dirname $@)
	g++ $(CXXFLAGS) -g3 -O0 $< -o $@ -lpthread -lgtest_main -lgmock $(OBJECTS) $(LDFLAGS)

.PHONY: test
test: $(TEST_SRCS)
	@for TEST in $(TEST_BINS); do 
		make "$$TEST"; 
		echo "Execute $(TEST)"; 
		./$$TEST; 
	done

Now you just need to run make test. Remember to add the proper Vim's mapping.

Makefiles

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:

# Dependency directoy
df=$(BUILD_DIR)/$(*D)/$(*F)

$(OBJECTS): $(BUILD_DIR)/%.o: %.cpp
	@mkdir -p $(BUILD_DIR)/$(*D)
	$(COMPILE.cpp) -MD -o $@ $<
	@cp $(df).d $(df).P; 
	sed -e 's/#.*//' -e 's/^[^:]*: *//' -e 's/ *\$$//' 
		-e '/^$$/ d' -e 's/$$/ :/' < $(df).d >> $(df).P; 
	rm -f $(df).d

$(MAIN_OBJ): $(MAIN_SRC)
	$(COMPILE.cpp) -MD -o $@ $< 

# Binary name depends on BIN_DIR/BIN_NAME, so the call to create BIN can
# be forwarded to BIN_DIR/BIN_NAME
$(BINARY): $(BIN_DIR)/$(BINARY)
$(BIN_DIR)/$(BINARY): $(OBJECTS) $(DEPS_OBJECTS) $(MAIN_OBJ)
	@mkdir -p $(BIN_DIR)
	@# Workaround for a linker bug: if the libs are not
	@# at the end it won't link (something to do with how the linker
	@# lists the dependencies... too long for a comment, rtfm
	g++ $(CXXFLAGS) $^ -o $(BIN_DIR)/$@ $(LDFLAGS)
	@#$(LINK.cpp) $^ -o $@

-include $(DEPENDS)

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

$(OBJECTS): $(BUILD_DIR)/%.o: %.cpp

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

$(MAIN_OBJ): $(MAIN_SRC)

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

$(BINARY): $(BIN_DIR)/$(BINARY)
$(BIN_DIR)/$(BINARY): $(OBJECTS) $(DEPS_OBJECTS) $(MAIN_OBJ)

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

Living on a null object

Check this out:

struct S {
   int f(){ return 42; }
};

int main() {
   S *x = (S*) NULL;
   return x->f();
}

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:

struct S {};

int mangled_S_f(struct S *this){
   return 42;
}

int main() {
   S *x = (S*) NULL;
   mangled_S_f(x);
}

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

Vacations are over

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:

Funny queries: What Google thinks of me

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:

Query	Impressions
grumpy old man	2,000
grumpy	400
grumpy man	400
ugly old man	250
grouchy old man	110
grumpy old	35
old grumpy man	70
grumpy gnome	12

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:

Query	Impressions
trained monkey	90
no life	90
funny troll
monkey using computer
tool monkey
congratulations monkey
monkey using tools

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

Query	Impressions
señal de muerte	12

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

Another common search:

hang yourself	200
how to hang yourself	90
rope to hang yourself	12

I guess those searches have a very low returning rate.

This is a query which sincerely surprised me:

Query	Impressions
eliphant
eiephant
elehant
elepant
eephant
elephanth

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

Final classes in C++

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:

class Final {
    protected:
    Final() {}
};

class X : virtual Final {
};

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:

class Final {
    protected:
    Final() {}
};

class X : virtual Final {
};

class Y : public X {
};

int main() {
    X x;
    Y y;
    return 0;
}

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.

LD magic in Linux

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:

export LD_DEBUG=help

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.

Cool C++0X features X: type inference with decltype

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:

template <class... Args>
auto wrap(Args... a) -> decltype( do_something(a...) ) { 
	std::cout << __PRETTY_FUNCTION__ << "n";
	return do_something(a...);
}

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:

auto foo(int x) -> decltype( bar(x) ) { 
	return bar(x);
}

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:

template <typename A, typename B>
auto multiply(A x, B y) -> decltype( x*y )
{ 
	return x*y;
}

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:

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

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:

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

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.

sshfs, quick remote mount

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

sshfs user@host:/path/to/remote/dir /path/to/local/dir

Remember you need permission for both local and remote directories.

Cool C++0X features IX: delayed type declaration

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

#include <iostream>

void do_something() { std::cout << __PRETTY_FUNCTION__ << "n"; }
void do_something(const char*) { std::cout << __PRETTY_FUNCTION__ << "n"; }
int do_something(int) { std::cout << __PRETTY_FUNCTION__ << "n"; return 123; }

template <class... Args>
auto wrap(Args... a) -> decltype( do_something(a...) ) { 
	std::cout << __PRETTY_FUNCTION__ << "n";
	return do_something(a...);
}

int main() {
	wrap();
	wrap("nice");
	int x = wrap(42);
	std::cout << x << "n";
	return 0;
}

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:

void foo() {}

Is the same as:

auto foo() -> void {}

Vim: Ni! Ni! Ni! Ni!

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?