Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[C++] Moving classes to header files
#1
So I have this code and I need to move the two objects to their own header files (StoryWordManager and MadLib). I need a .cpp file and a .h file for each object but what I don't understand is what goes where: what goes into the .h and what goes into the .cpp?

 Spoiler
Reply
#2
Been a while since I coded in C++, but I'm pretty sure you can move everything but the main class to the .h file.
Reply
#3
Pretty much. Main() is all you need in the cpp, everything else is just definition.

Headers are for describing, cpp's are for doing.
Reply
#4
So it would be...

StoryWordManager.h
Code:
class StoryWordManager
{
      public:
             StoryWordManager();
};


StoryWordManager.cpp
Code:
#include "StoryWordManager.h";

StoryWordManager::StoryWordManager()
{
     cout << "hello world\n" << endl;
}


main.cpp
Code:
#include "StoryWordManager.cpp";

int main()
{
    StoryWordManager userInput;

    return 0;
}

?

Feels redundant... compared to java anyway.
Reply
#5
No... You include headers, not other C files.

Both of your first two chunks would be in a single header because it's just a single class definition. Your third chunk would include that header, serve as the main entry point into the app and just happens to do nothing but call the instantiation member of your included class before it exits.
Reply
#6
The way I was told was to put the class declaration into the header file and the method definitions into the corresponding C++ file.

However (excuse my hijacking), would there be any problem with combining the two and putting it in a single header file, without a corresponding C++ file? I've always done that to be lazy and I wonder if there's actually any downside to it.
Reply
#7
That's how I've always done it.

The advantage/disadvantage stems from when you're going to include the header, because in a subtle way you're prepending the entirety of your includes onto the files they're included in and if you've only got the declarations and pointers in the header you're theoretically not including the whole enchilada in every file that the include is used in.

As far as I know that's all hooey thanks to modern compilers anyhow, since it does all the cross linking and assembling and doesn't actually shove the complete code in multiple places over and over.

Ultimately it's likely stylistic preference and comfortable organizational structure and nothing more.
Reply
#8
Eosian Wrote:Ultimately it's likely stylistic preference and comfortable organizational structure and nothing more.
Nope. The way Russt describes is the standard way of doing things (class interface in header, class implementation in cpp). Doing it that way allows you to change the implementation of a method and then only that cpp file will have be recompiled. If you put the implementation into the header, then any cpp that includes the header will have to be recompiled when any part of the implementation changes. Of course, you still have to recompile all cpp files that depend on that header file if you add private methods to the class or something. To get around that, you can use the PIMPL (pointer to implementation) idiom. And no matter what, templates have to be implemented in the header and you lose the ability to avoid recompilation like you do with normal classes.

Yes, having separate header and implementation files is redudant. Yes, C++ is hideously complex. No, there isn't any less sucky widely used language that lets you have OO and compilation to native code. I've heard about D, but I've never given it a try.
Reply
#9
I don't accept that particular reasoning for exactly the caveat you added - It separates the definition into two halves for no practical reason when you're going to have to recompile everything that either part touches in 85% of the reasons you'd ever touch it.

The practical advantage is next to NIL, although it's nice to know it has a theoretical one.
Reply
#10
Lucida Wrote:The way I was told was to put the class declaration into the header file and the method definitions into the corresponding C++ file.

However (excuse my hijacking), would there be any problem with combining the two and putting it in a single header file, without a corresponding C++ file? I've always done that to be lazy and I wonder if there's actually any downside to it.

This is how I learned to do it as well. I believe this is how most people are taught in the classroom and if you learn on your own, this is generally what you see in most cases.

I've never thought about putting it all in one, though.
I think I like the standard way of doing it. Seems more organized. Smile

.02c.
Reply
#11
I'm getting confused between Eos' vs the standard way of doing it.

In simplest words:
class declarations goes in .h
class methods goes in .cpp

So from the original code,

what goes in .h :
Code:
#ifndef STORYWORDMANAGER_H
#define STORYWORDMANAGER_H

class StoryWordManager {
};

#endif

What goes in .cpp :
Code:
StoryWordManager::StoryWordManager() {
}

string StoryWordManager::askText() {
}

That's what I'm understanding.
Reply
#12
With Object Oriented programming comes a concept calls "design by contract". What it essentially means is that you set a pre and post condition. While some languages support this inherently, others do not, thus you tend to have it as comments.

What goes in a .h file is generally the class definition (class variables and functions) and sometimes with the above mentioned contracts.

The advantage of splitting it into 2 files, .h and .cc/.cpp is that it keeps the declaration and definition separate. This allows you to change your definition without modifying the declaration (as mentioned above). This allows libraries to exist without actually releasing your implementation source and it also isolate changes.

With design by contract in place, your method essentially guarantees that "you give me the right inputs and i'll give you the right outputs". A simple example of this may be:

public function square_integer(int intput)
{
// pre: input has to be an integer

// post: output will be an integer and will be >= 0
}

(do note that I ignore certain conditions on purpose). Those information will be enough to enable you to use an external class.
Reply
#13
butterfλi Wrote:I'm getting confused between Eos' vs the standard way of doing it.

In simplest words:
class declarations goes in .h
class methods goes in .cpp

So from the original code,

what goes in .h :
Code:
#ifndef STORYWORDMANAGER_H
#define STORYWORDMANAGER_H

class StoryWordManager {
};

#endif

What goes in .cpp :
Code:
StoryWordManager::StoryWordManager() {
}

string StoryWordManager::askText() {
}

That's what I'm understanding.

No. The class declaration encompasses all method declarations, so your .h would be:

Code:
#ifndef STORYWORDMANAGER_H
#define STORYWORDMANAGER_H

class StoryWordManager {
  StoryWordManager();
  string askText();
};

#endif
Reply
#14
Russt Wrote:No. The class declaration encompasses all method declarations, so your .h would be:

Code:
#ifndef STORYWORDMANAGER_H
#define STORYWORDMANAGER_H

class StoryWordManager {
  StoryWordManager();
  string askText();
};

#endif

Right. I figured it out. The constructor, date members and member functions goes in class declaration.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)