Nicolás Brailovsky

There are not many cases in which you can have an anonymous *anything* in your code, yet there’s an idiom in C++ which lets you use an object with an anonymous type. Like this:

void foo()
{
   struct {
      int x;
   };
}

Why would this be useful, you may ask. That’s a valid question. This idiom can be very useful to write callbacks, like this:

struct Interface {
   void callback() = 0;
};

void bar(Interface &c);

void foo()
{
   struct : public Interface {
      /* ... */
   } x;

   bar(x);
}

I am not aware of many other uses for an anonymous type. Even more considering this idiom can now be replaced with a much cleaner lambda. But hey, it looks cool!

Quite a mouthful for such an easy thing. Don’t you just hate when half the people in a project use CR/LF and the other half just LF?

Luckly this is easy to fix, assuming you are using svn. You can use something called auto-props to setup the eol style for different file types.

Set it once for the project, never worry again. Anyone knows its git counterpart?

I like Google test and Google mock (C++ only) a lot. These are really great tools to ensure the quality of your code. They do have one problem however, especially when working with a legacy codebase: many times you need to change a signature for a function and your tests begin to fail. Those tests shouldn’t really fail, they shouldn’t compile at all because you’re now trying to mock a function which doesn’t exists anymore.

I worked on a patch to check if a class and its parent share the same methods, but I hit some major roadblocks which I believe cannot be saved:

• You have no way of detecting if the parent’s method is actually virtual. It may have the same signature, yet if it isn’t virtual the mock serves no purpose
• You have no (easy) way of detecting if the method is defined in your parent’s parent

Even though this code will never be useful, I thought I might as well post this here, just in case anyone comes up with a solution for those problems.

Even though the title says svn, this tip is applicable probably for any version control system. Imagine the following scenario: You have project BestAppEver. BestAppEver depends on BestLibEver. Both are using svn. How do you handle this on your version control system?

One way, the wrong way, that I have seen lots of times is to just include a copy of BestLibEver inside BestAppEver, like this:

This is horrible, whenever BestLibEver is updated you need to manually update BestAppEver. Thus, we come to the second (but not quite the best) solution: svn externals. They work like this:

Again, although I said svn externals, most version control systems have their own externals version. For a detailed explanation on how externals work you should read the link above, for the moment let’s just say this is enough to setup the external:

Now every time you run an svn update, it will fetch the latest version of BestLibEver. We have a problem though: BestLibEver may be a project with a lot of commits, and the head revision may be very unstable. Not only it may crash (being a development version, it wouldn’t be a strange thing) but also its interfaces may be constantly changing. And we certainly don’t want to spend all day just changing our wrappers to make the project compile again.

There is a solution for this, and we don’t have to go back to the first method of just copying the trunk to our repository: we can ask the maintainer of BestLibEver to just create a branch (or a tag, for this case it’s pretty much the same) for a stable version and then use an external to that branch. Like this:

Now the team developing BestLibEver can work without complaints from their users and BestAppEver can have a stable svn, with controlled lib upgrades whenever they want.

There is a topic I have referred to several times on this blog, yet in four years I still haven’t explained what it is. I plan to correct this by explaining a little bit about C++ name mangling, and although I won’t expect to write anything you couldn’t learn by reading Wikipedia, I’ll try to have a more practical approach.

Whenever you compile and link something, there is a lot of information the compiler deduces that you don’t really care about. Things like calling conventions, overloads or namespaces. Yet this information is crucial for other stages of the compiler (or linker) to work. For this reason, the compiler will create a decorated version of any object’s or function’s name.

In its most simple case, it would be something like this:

Which would then be translated to something like:

Of course, for more complex functions (like class methods) the mangling is much more complicated. Also, remember that’s just a mangling convention I just invented, and most likely not used by any compiler in existence.

Although for the most part we can just ignore name mangling, this has a couple of consequences of which we should be aware:

Creating a name for anonymous objects/functions

I will not explain much about this, it might be the topic of another post, but there are certain cases in which you can have a struct or a function defined inside another object anonymously. In these cases, the mangler will assign some sort of denomination for this anonymous object.

Linking with C symbols

C has no mangling. It just doesn’t need it. This has a very important consequence, whenever you use C code in C++ you need to specify that your doing so, by using an extern “C” declaration.

Debugging

gdb already takes care of this so it may be transparent to you, but if you are using a debugger not aware of how your compiler mangles names, you may end up with a lot of very difficult to understand names.

Bonus: Demangling C++ names

If you find yourself in the last case, for example when running an nm to get the names defined in a (compiled) object, you can use c++ filt. Like this:

Last time we saw how you can use C style array-initialization for C++ objects, like this:

We also saw this works for may types of objects, like maps and pairs. How about custom developed objects? Yes, that’s right, you can have initilizer lists for your own objects too, and it’s quite easy. C++0x offers initializer_lists which you can use on your constructors (or any other methods, for that mater) to have C-style initialization. Let’s see an example. We already know how to sum a list of numbers using template lists and variadic templates, so let’s try adding an initializer consisting of numbers:

Let’s start by creating a class which can accept an initializer list:

That’s interesting, as you can see an initializer list is actualy a template class, meaning that nested initializers can easily be defined too. Now, we have the interface, how can we access each element of the list? Let’s do the same thing I did when I found out about initilizers, let’s search for the header file.

Looks surprisingly easy (note that this is for G++ 4.something only). And it is, most of the magic happens in the compiler, so the userland code is quite straight forward. According to that header file, we could build something like this:

As you can see, the initializer lists can be used in any place an iterable container is required, as long as it’s const. There’s not much more magic to it, but we can use some more C++0x devices to make our list-adding device much more cool, for example to support different actions and not only addition. Next time, though.

PS: An important lesson from this article: don’t be afraid to look into the system headers, they won’t bite. You should never ever change them, but taking a peek can only improve your C++ knowledge.

We talked last time about ranged fors and how they can simplify our life in C++0x. Now we are going to take a trip back to old C land. Remember when you could initialize your arrays like this:

C++ brought a lot of changes to the world, and suddenly instead of int[] you were supposed to use vector, and with it your initializer didn’t work anymore. Though luck. Try to compile this:

If you did compile it with g++, you may have noticed an interesting error message:

That’s interesting. Try to compile it with g++ again, but using C++0x instead of plain C++. Magic, now it works!

Initializers lists bring the best of C to C++ world (?) by letting you use initialize any object with an initializer. And I mean *any* object, not just vectors. For example, say you have a map (a map and a bunch of other stuff):

Yes, that works! Maps, vectors, pairs, and even your own custom objects, but we’ll see that next time.

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.

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:

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:

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

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:

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.

After a long, long hiatus, the C++0x series are back. You may want to check where we left by reading the last posts of this series.

In the last few entries we saw how to use decltype for type inference. Object types is a problem that seems easy but gets complicated very quickly, for example when you start dealing with constness. Constness is difficult in many ways but this time I want to review how constness works with type inference. This topic is not C++0x specific as it’s present for template type deduction too, but decltype adds a new level of complexity to it.

Let’s start with an example. Would this compile?

Clearly not, having a const Foo means you can’t touch foo.bar. How about this?

That won’t compile either, you can’t initialize an int reference from a const int, yet we can do this:

If we know that works it must mean that s.result’s type is const int. Right? Depends.

Just as the name implies decltype yields the declared type of a variable, and what’s the declared type for Foo.bar?

That’s an interesting difference, but it makes sense once you are used to it. To make things more interesting, what happens if you start adding parenthesis (almost) randomly? Try to deduce the type of x:

If decltype(x) is the type of x then decltype((foo.bar)) is the type of (foo.bar). Between foo.bar and (foo.bar) there’s a very important difference; the first refers to a variable whilst the last refers to an expression. Even though foo.bar was declared as int, the expression (foo.bar) will yield a const int&, since that’s the type (though implicit and not declared, since the expression is not declared).

This is how we would complete the example then:

As I said, disappearing constness is not a C++0x specific problem as it may occur on template type deduction, but that’s besides the point of this post. Next time we’ll continue working with type deduction, but with the new auto feature this time.

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.