Olivier Langlois's blog

In the book The C++ Programming language from Bjarne Stroustrup, you can read in section 5.7 (Structures):

The size of an object of a structure type is not necessarily the sum of the sizes of its members. This is because many machines require objects of certain types to be allocated on architecture dependant boundaries or handle such objects much more efficiently if they are. For example, integers are often allocated on word boundaries. On such machines, objects are said to have to be aligned properly. This leads to "holes" in the structures...You can minimize wasted space by simply ordering members by size (largest member first).

As an example, on my platform if I write:

struct MyPOD1
{
  bool a;
  int  b;
  bool c
  int  d;
};

struct MyPOD2
{
  int  b;
  int  d;
  bool a;
  bool c;
};

sizeof(MyPOD1) is 16 and sizeof(MyPOD2) is 12. which means that 4 bytes are wasted by the MyPOD1 layout. Bjarne continues by adding that you should prefer readability over memory usage optimization but in my opinion taking the habit of always placing 1 byte variables such as bools and chars at the end of a class data members declaration can hardly obfuscate the code especially if the class encapsulation is tight.

Now that the demonstration that by just reordering data members around in a class declaration can save space has been done, let me explain to you the advantages of saving few bytes. Just imagine that you have a std::vector<MyPOD2> of 25K elements. You just saved 100KB of space to your program for free and since more elements will fit in the processor cache which should make the vector traversal faster.

I recommend taking this habit because it is easy to do and once you get used to do it, it will become an automatism and you will get the best performance from your data structures without having to stop and think about how you could optimize them before you need to.

Which is better

void f(int &a);

or

void f(int *a);

?

Once compiled, there should not be any difference between the 2 versions as references are most likely implemented with pointers under the compiler hood. The main difference between passing a pointer to a function vs a reference is that with the reference you are sure that the reference points to a valid object where as with pointers you could pass a NULL pointer.

Hence, if a NULL pointer is not a valid value for a function, you can enforce that fact by passing a reference. Some people argue that it is possible to have dangling references by doing:

int &f()
{
    int a;
    a = 5;
    return a;
}

int main(int argc, char *argv)
{
    int &r = f();
    return 0;
}

or

int main(int argc, char *argv)
{
    int *p = new int(5);
    int &r = *p;
    delete p;
    return 0;
}

but I consider these cases pathological and my opinion is that references are safer than pointers because:

1. They behave like const pointers.
2. They must be initialized at their declaration.

With these, it should be much harder to have *unintentionally* dangling references than having uninitialized pointers especially if you do not do the newbie mistake of returning a reference to a local variable. My C++ debugging experience has led to me to fix plenty of pointer problems but I have never seen until now a dangling reference problem in real code.

Also, Scott Meyers, in his book More Effective C++ (item 1: Distinguish between pointers and references), goes in the same way about this issue.

I have writen a new tutorial that presents an example on how to incorporate CFixeAlloc optimization into existing MFC software.

You can read it here and leave comments on it here.

I just published the second part of the serie on C programs refactoring in C++. Here is the introduction of this tutorial:

In the first part of the serie, I presented guidelines that needs to be followed when someone wish to use C++ from C programs. In an ideal world, the old C programs that you want to port to C++ should be rewritten completely. However in the real world, due to economical constraints, this is usually impossible and a more gradual approach must be adopted. During the transition period, to maximize the benefits of using C++ and to not end up with having a program consisting of just a bunch of C interfaces with C++ implementations, you can identify some patterns in the C program and refactor them appropriately. By having gone through the exercise myself, I am presenting the techniques that I have discovered and I will be discussing the benefits and the potential pitfalls of these refactoring patterns.

You can read the rest here.

I have written a new tutorial available on my website. Here is a small quote from the introduction that describes what it is about:

In this tutorial, I will introduce the simple guidelines and pitfalls to avoid when using C++ in C programs. The second part will continue by presenting higher level patterns to leverage the good software architecture patterns that C++ language facilities encourage into C programs.

You can read the rest here.