C++ Method prototype/Implimentation
Author
My job and my free time at home intails alot of source code reading and documentation and reviewing. One of the common thing's im starting to see within some HPP files is that the code is actualy implimented within the header files itself, similar to how java mixes implimentation and defintion of the classes. Typicaly the code is not inlined and describes the complete class from top to bottom, without the need of a cpp file.
For example (old way)
//cat.h
class cat : animal
{
public:
void method();
};
//cat.cpp
cat::method()
{
// code! lots of it!
}
new common way?!
//cat.h
class cat : animal
{
public:
void method()
{
// code! lots of it!
};
};
What limitations do you impose on yourself if you do follow this approach? or do you actualy do it yourself. Im intrested to find out. The only logical thing i can come to conclusion about this method or proccess is your limited to the header files you can give your clients if they wish to use your code. Next is considering that the compiler does not create a obj file or lib file for the object it means that each time the code is compiled it has to walk your source code again and recomile the obj file and link it into your main application.
Any suggestions or thoughts about the issue is most welcome.
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.
Quote:Original post by doodoMy (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:
What limitations do you impose on yourself if you do follow this approach?
void incrementAll() { for( int i = 0; i < m_size; i++ ) m_data++;}
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.
However, I do agree with DaBono and tend to throw setters and getters into the header files.
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.
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.
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:
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) - ...This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
