Understanding constructor placement

[kacko]

So I was looking over the Classes TUT here at C++.com (found here http://www.cplusplus.com/doc/tutorial/classes.html) and I noticed that during the planning of the class, they use a prototype withing the class definition, but declare the constructor and destructor outside of the class definition.

Like such:

class CRectangle {
    int *width, *height;
  public:
    CRectangle (int,int);
    ~CRectangle ();
    int area () {return (*width * *height);}
};

CRectangle::CRectangle (int a, int b) {
  width = new int;
  height = new int;
  *width = a;
  *height = b;
}

Is it safe/better to it this way? Is it the only way to do it?

I think I have seen it used inside the actual definition of the class, just as long as it is after the public: statement.

Like this:

class CRectangle {
    int *width, *height;
  public:
      CRectangle (int a, int b) {
      width = new int;
      height = new int;
      *width = a;
      *height = b;
     }

    ~CRectangle ();
    int area () {return (*width * *height);}
};

So for the final question,

Which will work,and if both, which is better? Is it merely a matter of preference?

Happy Coding!


EDIT: I answered my own question about which one works, both do, but which one is favored??

[Mitsakos]

They both work.
When you declare a function inside a class then it is automatically inline function.
I think that's the only difference. If you want it inline then declare it in the class. If you don't, make a prototype in the class and declare it outside the class.

Hope this helps

[Zaita]

I am going to disagree with Mitsakos here (sorry man).

Best practice, your declaration of the class should be in a .h file and the implementation (the code) should be in a .cpp file.

You do this because if you start putting your actual code in the same file as the declaration VERY shortly you are going to end up with compiler errors due to dependencies amongst classes. Your code should be separated from the declaration as a way to avoid cyclic-dependencies.

[Mitsakos]

I just sayed that if it is in the class declaration it is automatically inline.
Isn't it true?

Now I understand why you have the declaration in .h files and the implementation in your .cpp file... I was always reading that in books but nobody ever explained why... Thank you about that.

[Zaita]

It could be inline, but this would be a compiler specific setting (As far as I know).

I usually keep get/set methods in the .h file. This is because they are short and require no depdencies. Having them inline wouldn't make much difference.

e.g

class CBaseConfigLoader {
public:
	CBaseConfigLoader();
	virtual void              processConfigFile() = 0;
	void                      setFileName(string value) { sFileName = value; }
	string                    getFileName() { return sFileName; }
	void                      setDirectory(string value) { sDirectory = value; }
	string                    getDirectory() { return sDirectory; }
        virtual                   ~CBaseConfigLoader();

[Mitsakos]

That is what I usually do also. I just have them all in my main cpp file not in separate files. I'll try the separate files because I get really confused in bigger programs

I found this for the inline functions in class:

A member function defined within the class definition – rather than simply declared there – is taken to be an inline member function.
From "The C++ Programming Language Third Edition" by Bjarne Stroustrup

[kacko]

So best practice, separate them into two diffrent files,

thanks!

[Zaita]

Yes.

When you do Object-Orientated development it's usually 1 class per file-pair.

e.g a class called "Banana" would have "Banana.h" and "Banana.cpp". The file naming maybe slightly different based on the coding-standard you use (I would have "CBanana.h" etc)

[Zaita]

Why inline?

As you probably noticed, it's definitely fewer keystrokes to inline a function. However, another good reason to inline is that you can sometimes speed up your program by inlining the right function. Instead of calling the function every time it is invoked, the compiler will replace the function call with a copy of the function body. If it's a small function which gets called a lot, this can sometimes speed things up.

This is another reason why I inline my get/set methods also :) But do note that it says "can sometimes" speed.