Nicolás Brailovsky » C++

Anonymous objects in C++

nico — Tue, 20 Dec 2011 09:00:54 +0000

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!

C++: Checking if a method exists in a parent class

nico — Thu, 08 Dec 2011 09:00:56 +0000

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.

// :!g++ foo.cpp -lgtest_main -lgmock && ./a.out
#include
#include
using namespace testing;
/**
* "Real" application
*/
class Foo {
public:
virtual int bar(int) { return 1; }
//virtual int bar(void) { return 1; }
};
class Do {
public:
int something(Foo &foo){ return foo.bar(1); }
};
/**
* Class used to compare method ptrs. We need to inherit from class C
* to forward the calls to the derived methods.
*/
template
class Mocks_Must_Exist_In : public C {
public:
// We don’t know in the derived class the typeof the parent class
// so we define a common name using some template magic
typedef C ParentClass;
// Actually we don’t know our own class either
typedef D Self;
// Function ptr definitions are ugly so we might as well use
// a template to hide it under the rug
template
void mock_created_for_unexisting_method(F f, G g){ f = g; }
};
#define METHOD_EXISTS(Method) \
void defined_##Method() { \
mock_created_for_unexisting_method(&Self::Method, &ParentClass::Method); \
} \
/**
* Checked mock, shouldn’t compile if Foo’s interface changes
*/
class FooMock : public Mocks_Must_Exist_In< Foo, FooMock > {
public:
MOCK_METHOD1(bar, int(int));
METHOD_EXISTS(bar);
};
/**
* Unchecked mock, should compile if Foo’s interface changes
*/
class FooMock2 {
public:
MOCK_METHOD0(bar, int());
};
TEST(FooTest, ThisShouldCompile) {
FooMock foo;
EXPECT_CALL(foo, bar(_)).WillOnce(Return(42));
EXPECT_EQ(42, Do().something(foo));
}

C++ name mangling

nico — Thu, 17 Nov 2011 07:00:32 +0000

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:

void overloaded_function(int);
void overloaded_function(string);

Which would then be translated to something like:

void fastcall_int_overloaded_function(int);
void fastcall_string_overloaded_function(string);

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:

nm foo.o | c++filt

Cool C++0X features XV: Initializer lists for custom (non-std) objects

nico — Tue, 18 Oct 2011 10:00:38 +0000

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

std::vector v = {1,2,3,4};

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:

#include
using namespace std;
struct Add_List {
Add_List(initializer_list lst) {
}
};
int main() {
Add_List x = {1, 2, 3};
return 0;
}

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.

template
class initializer_list
{
public:
typedef _E value_type;
typedef const _E& reference;
typedef const _E& const_reference;
typedef size_t size_type;
typedef const _E* iterator;
typedef const _E* const_iterator;
private:
iterator _M_array;
size_type _M_len;
// The compiler can call a private constructor.
initializer_list(const_iterator __a, size_type __l)
: _M_array(__a), _M_len(__l) { }
public:
initializer_list() : _M_array(NULL), _M_len(0) { }
// Number of elements.
size_type
size() const { return _M_len; }
// First element.
const_iterator
begin() const { return _M_array; }
// One past the last element.
const_iterator
end() const { return begin() + size(); }
};

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:

#include
#include
using namespace std;
struct Add_List {
Add_List(initializer_list lst) {
int sum = 0;
for (auto i = lst.begin(); i != lst.end(); ++i)
sum += *i;
cout << sum << "\n";
}
};
int main() {
Add_List x = {1, 2, 3};
return 0;
}

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.

Cool C++0X features XIV: Initializer lists

nico — Tue, 11 Oct 2011 10:00:22 +0000

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:

int v[] = {1, 2, 3, 4};

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:

#include
int main() {
std::vector v = {1,2,3,4};
return 0;
}

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

error: in C++98 ‘v’ must be initialized by constructor, not by ‘{…}’
warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x

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

int main() {
map> v = {
{ "a", {1,2,3} },
{ "b", {4,5,6} },
{ "c", {7,8,9} }
};
cout << v["b"][1] << "\n";
return 0;
}

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

Cool C++0X features XII: type inference with auto

nico — Tue, 04 Oct 2011 10:00:17 +0000

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.

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

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:

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

int x = 2;
int y = 3;
auto z = x*y;

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:

for (FooContainer::const_iterator i = foobar.begin(); i != foobar.end(); ++i)

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

for (auto i = foobar.begin(); i != foobar.end(); ++i)

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:

Wrong

void f(auto x) {
cout << x;
}

Right

template
void f(T x) {
cout << x;
}

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.

Cool C++0X features XI: decltype and disappearing constness

nico — Tue, 27 Sep 2011 10:00:15 +0000

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?

struct Foo {
int bar;
};
void f(const Foo foo)
{
foo.bar = 42;
}

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

struct Foo {
int bar;
};
void f(const Foo foo)
{
int& x = foo.bar;
}

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

void f(const Foo foo)
{
const int& x = foo.bar;
}

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?

struct Foo {
int bar;
};
void f(const Foo foo)
{
// This won’t compile
int& x = foo.bar;
// This will
decltype(foo.bar) x = 42;
}

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:

void f(const Foo foo)
{
decltype((foo.bar)) 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:

void f(const Foo foo)
{
// This two statements are equivalent
decltype((foo.bar)) x = 42;
const int& y = 42;
// It’s very easy to confirm that the typeof x is now const int&
// This won’t compile:
x = 24;
}

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.

Throwing destructors

nico — Tue, 20 Sep 2011 10:00:44 +0000

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.

Living on a null object

nico — Tue, 16 Aug 2011 10:00:26 +0000

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

Final classes in C++

nico — Tue, 05 Jul 2011 10:00:41 +0000

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.