Is there any difference between the ways of declaring classes in C++?

Question

Ever since I started learning C++ I’ve always done something like:

class. h

#ifndef CLASSE_H
#define CLASSE_H

class OutraClasse;

class Classe
{
   public:
      Classe();
      void foo(OutraClasse *bar);
};

#endif

And here I declare the methods, builder and other things cpp class.:

#include "classe.h"
#include <OutraClasse>

Classe::Classe()
{
    //Algo aqui
}

void Classe::foo(OutraClasse *foo) {
    //Algo aqui
}

But I notice that eventually some class are written only in .h thus:

#ifndef CLASSE_H
#define CLASSE_H

#include <OutraClasse>

class Classe : public OutraClasse
{
   public:
       Classe() {
           //Algo aqui
       }

       void foo(OutraClasse *bar) {
           //Algo aqui
       }
};

#endif

The main.cpp would look something like both:

#include "classe.h"
#include <OutraClasse>

int main()
{
    OutraClasse outra;

    Classe foobar;
    foobar.foo(&outra);
}

I would like to know if this influences the compilation or post-compilation, for example execution, this due to the statement order of headers, I mean, if I understood correctly the first example I quoted works very just call OutraClasse when foobar is used, in the second example it would be called at all times.

Is there any difference for compilation, execution or performance?

Answer 1

Put everything into header

The great advantage is to enable better optimizations. If you want implementations to be inline have to do this. The same goes for the use of templates that there’s always a inline feedback, it is never solved at runtime. I speak of this in another question.

The fact that inline requires recompiling all consumers every time they change something in class. This is good or bad depending on what you want.

There is a clear disadvantage: all class code will always have to be recompiled when this class is used (it is even possible to have some cache what help). There is the highest compilation cost in that case.

If the optimization is done there will be no indirect. The performance tends to be slightly better. This usually makes sense in codes that need high performance. It doesn’t help much in GUI, for example.

Have the implementation in a separate file

The great advantage is not having to compile the algorithm every time you use it, it is separated from the statement. In compensation you will have to recompile the algorithm file whenever you change it for the rest of the code to see. If you forget to do this, in theory everything will work, but you will access the old version, which is not what you want, you can go unnoticed.

The advantage is not only the cost of reduced compilation, but it has a different semantics in code modifications. While it is a disadvantage to have to recompile implementation for consumers to see, consumers do not need to be aware of the change in implementation. You can recompile the class without requiring recompilation from your customers, as long as the API remains the same. The API is what’s in the header.

These codes cannot be optimized by inline at the places of its use. There will always be an indirect, like every non-linear function.

This is the most common option in most cases, but the other is well used as well. You have to master these implications well to make the right choice, but in doubt the pattern is this, everyone is well accustomed to it (I’m not saying it’s the best ever, only that it’s the most acceptable when you don’t know what to do and the other isn’t mandatory).

There’s one more question that may be useful.

Answer 2

Methods defined in the class declaration are automatically considered "inline" by the compiler.

The compiler can generate "inline" code for these methods, that is, it does not create a function that encapsulates this code, and in each method call the code is copied in place of the method call, rather than effectively calling the method. Effectively an inline function is like an intelligent macro.

In principle the compiler only creates inline code for very small functions, but this is at the compiler’s sole discretion, which can eventually simply disregard this possibility, and actually create functions to implement all inline methods.

class Classe : public OutraClasse
{
   public:
   Classe() {
       //Algo aqui
   }

   void foo(OutraClasse *bar) {
       //Algo aqui
   }
};