C++ class constructor

Question

I have a skeleton for a class as follow:

class MyList
{
    private:
    public:MyList(int);    // why can't I define stuffs here?
};

MyList::MyList(int s)     // why is this outside of the class?
{
}

I wonder why the constructor is put outside of the class itself? Wouldn't it be more compact and nicer to have it placed inside the class itself?

Answer 1

You absolutely can make the constructor inline ("Java style") if you want, and for simple one-lined methods that are unlikely to change very often, that is often the way to go.

The question you may be asking is, what is the point of allowing the non-inline version, when doing it inline requires less typing and fewer files to manage?

There are several reasons you might want to do a non-inline constructor (or non-inline style of any method, really):

1. Since .h files get #included by other files, anytime you change a .h file, any .cpp file that #includes it (as well as any .cpp files that include a .h file that includes your .h file) may need to be recompiled. This can make development slow if your program is large and/or you need to change inline methods a lot.

2. Separating the method's body from its definition gives you a way to solve the circular-include problem -- eg it would allow you to have two classes whose method arguments each refer to the other class (by pointer or reference). With only inline code, the method-bodies of one of those two classes would have to be parsed before the other class's .h file was parsed, which would likely result in "incomplete type" or "unknown type" compilation errors.

Answer 2

I wonder why the constructor is put outside of the class itself?

The function definition can be put outside or it can be kept inside. This applies to all member functions, not just constructors. So, let me make your question more general: What is the advantage of defining member functions outside of the class?

It allows keeping the definition of the class short and concise. This is useful in keeping the class definition readable: The member declarations are the most useful information to the user of a class who reads its definition. The definition of the member functions is often an implementation detail that can't or shouldn't be relied on.

It also allows defining the member functions in a separate source file instead of being defined inline in all of the source files that include the class.

So, the advantages are same as separating forward declarations of free functions from their definition. A list of function declarations in a header is analogous to a concise class definition with no inline function definitions.

Defining a function (member or otherwise) out-of-line in its own source file instead of inline of all source files is useful because it allows that single source file to be compiled separately. If any change is made to the function, no other source file need to be compiled. In the inline case, all source files that use the function would have to be compiled again. Likewise, whenever any other source file is compiled, there is no need to compile the out-of-line function from another source file, but an inline function must be compiled in each source file.

---

These general advantages hardly apply to your trivial example constructor. It is an ideal candidate for inline definition, because its call can be completely optimized away. Also, it is so short that it doesn't affect readability of the class. As such, I would recommend to not define that constructor outside of the class itself.

Answer 3

You can place the constructor definition in the class definition. Both ways work just like other functions. Where you place it depends on stuff like the length of the definition.

Answer 4

You can put the constructor at either place. The compiler does not make distinction. However, it is more of convention you follow in your team. Some groups follow the convention on defining everything in the *.cpp file, starting with standard methods like constructor, destructor, copy-constructor, operator-overloading followed by user defined methods.

It makes the code easy to read, maintain as the codebase expands.