# C++ Method prototype/Implimentation

This topic is 4259 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

##### Share on other sites
no, that's fortunately neither new or common, and it is hopefully never going to be. There may however be scenarios where you possibly benefit from not following the conventions.

##### Share on other sites
Quote:
 Original post by doodoWhat limitations do you impose on yourself if you do follow this approach?
My (soft) limit: implementations in header files (excluding templates) can't be longer than 2 lines. So, getters and setters are usually in the header files (that way the compiler can inline them wherever they're used), and simple stuff like:
void incrementAll() {   for( int i = 0; i < m_size; i++ )      m_data[i]++;}

##### Share on other sites
Implementing only in the header files seems like a horrible idea. The main reason being any small change in the code for the class will result in re-compilation of the header file and any source that includes it. This can be tremendously long for large projects.

However, I do agree with DaBono and tend to throw setters and getters into the header files.

##### Share on other sites
wow! i originaly came onto the boards to re-write the post. Considering it has been acouple of days and there was no real reply to it, so i thought my exsplaination about the issue was not writen very cleanly.

I do appogies for the post though, i really shoult of said: Placing the implimentation within the definition of the class. Would of been so much easier for myself and people reading the post.

Although, Im adimit at best to try to avoid the issue with splitting the implimentaiton and definition of a class in C++, consider to me it seems like a very high over-head in terms of software development and reusing code. Let me clarify that point alittle better.

Lets take for example you have 100 classes, each one would require a definition and implimentation file. This brings the tottal amount of files needing to be checked and opened and edited to 200 files if following the above procedure. So from my point of view, i sort of want to limit the number of files one has to go about editing well maintain low compile times.

My main programing and professional programing is still within the java language runtime enviroment. Its just recently i've dedicated myself in game programing and hurristic AI system that i have choosen the path of C++. So im alittle stubern when im confrunted in maintain one extra file instead of one.

Looking at the situation and seeing that its better to work with the compiler than against it. Can any of you recommend a good type of procedure you follow the help out in this area. For example split view, Two monitors, ect...

Please i dont want to start a flame war about java v c++ on the forum. Im dedicated in learning C++ and want to learn from others experiences so i dont make the same mistakes.

##### Share on other sites
Yes balancing the seperation into header and source files in C or C++ can be tricky to get right. You'll find that it makes sense to split your program/library into multiple modules (static/dynamic libraries). If you treat each library as a seperate program or codebase then this usually reduces compile times and dependencies between the modules a lot.

Assuming you write a library, then another way to reduce compile times (on the end user side) is to put all internal class definitions etc. into one or more private header files. Design the public interface first (to avoid lots of API changes later) and leave the public stuff only in as few headers as possible (IMHO), no implementation at all in there, but ideally a lot of documentation/comments. With the private stuff in seperate headers you can easily mess with the internals of the library without breaking any code used by other programmers (even if the 'other programmers' is just you).

I usually configure all my projects like this:

+include (end users include these) - library.h (public API) - library_conf.h (build-time configuration etc.)+src - library_private.h (privately included only by the lib, never by endusers) - library_stuff.cpp (implementation of class Stuff) - library_things.cpp (implementation of class Things) - library_foo.cpp  (implementation of class Foo) - ...