Why just use prototypes with classes?

When you write a class function, why is it bad form to make it anything other than a prototype within the class? In other words, why is it usually good form to define the function outside of the class definition?

The way I understood it, classes were supposed to be portable lines of programming that somewhat resembling real-life objects, actions, and so on (or fantasitical stuff, but symbolic as opposed to procedural). If this is so, then would it not be a waste of time to write a class full of defaultly useless variables and functions, then in the less portable areas of the program, finally write the data that makes the class useful?

When I program, I don't need somebody else helping me name my own variables and functions. But what I would possibly need from somebody else would be code that actually does stuff. Function libraries, for example.

I understand that even if a class variable or function is defined elsewhere in the program, it will be completely hand-in-hand with that class, and the classes created on one particular program might help speed up the programming process in that specific case. But when they are ported to another program, as I understand they oftentimes are, why not put the variable and function definitions inside the class to actually make it useful?

> When you write a class function, why is it bad form to make it anything other than a prototype within the class? In other words, why is it usually good form to define the function outside of the class definition?

Keep in mind, functions defined inside class definitions are marked as inline by the compiler. http://www.parashift.com/c++-faq-lit...s.html#faq-9.8

I suppose it might lead to excessively large executables, and it would definitely be messier code to read.

I can't make sense of the rest of your post.

Your post was very hard to understand but I think I understood it. As for your first question, it's better to split them up if you do not wish the functions to be inlined because it makes the code easier to read. For example, if you simply want to check what are the methods of a class, you don't want to scroll through all of the implementation details, you want to have a look at how the class is designed. As for your second question, well it's not that hard to include a few files in your project to re-use a class.

I probably cannot come with all the answers. But maybe the following will lead you somewhere. Others may be more incisive tha I will.

First and foremost you have to consider code readability. This should always be your major concern whether you are designing a class or deep inside main(). A class header file that shows itself only as a series of data members and function prototypes is a much easier class to understand, both by you that wrote it and to anyone else. Even simple class definitions that return or set data member values will distract the reader from the class structure that is usually what one wants to see when looking at it from an advantage point. Mainly what you want is to give the class user a bird's eye view of your class.

But there is more to it. Any function defined inside a class definition is by default a candidate for inlining. While it is true the compiler will do that choice for you, it is nonetheless a fact that you may not always want inlining to occur. At the very least you may want to have a say on this matter, even if the compiler sees that function as a good candidate. And this is so because of http://www.parashift.com/c++-faq-lit...s.html#faq-9.3

And there is also more to it. Some functions, depending on how your class is constructed, will only really do their thing if the class is fully defined. This may be so, because they need to access other member functions that have yet not been declared, for instance. You will find yourself in a bind if you have two functions referring to each other somewhere inisde their definition. You will end up having to prototype one of them, needlessly complicating your class definition to a point it simple becomes unredable and unmaintanable.

And finally... the least important of the reasons, but still a valid one. While separating the "interface from the implementation" paradigm of class development should be seen as a code technique, not as a data hiding feature, it is no less true that we should try and mimic it to some extent in the way we code our class. At least, to make the interface clear to the class user. This argument could be seen as a repeat of the first. But the truth is that we realy don't want to hide the implementation from the class user. It can be useful to them to learn how the class implements its features. We simply want the logical separation between interface and implementation to be more obvious to the human brain.

I never define any function inside the class defintion as a norm. I reserve that only to very small classes or structs. Even my inlined functions are defined inside the header file after the class definition. You don't need to go to that extreme (although you will not see me looking at this as an "extreme" approach). But you should look at class defintions the same way you look at any other header file and that is:

- header files contain declarations, const definitions and inline function defintions
- cpp files contains the defintions.

MS "Visual Studio form designer" always defines objects inside the form class.

Keeping code in the .h files increases compile times. Everytime you change the code, every file that includes that .h file needs to be recompiled. If you have a large project, that can mean hours vs a few seconds if it were in the .cpp.

I think the second point of your post summarizes as "isn't it better to have one file that you can reuse on other projects than needing to worry about two files?" If that is what you were trying to say, then don't worry, you'll get used to keeping .h and .cpp files paired up.