🔒 Locked

C++ Method prototype/Implimentation

Started by doodo May 21, 2006 at 11:14 PM 4 replies 1k views

Original Post

May 21, 2006 at 11:14 PM

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.

DaBono

103

DaBono

May 23, 2006 at 5:50 AM

Quote:
Original post by doodo
What 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++;}

dfranzi

May 23, 2006 at 12:12 PM

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.

basement

May 24, 2006 at 2:16 AM

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) - ...

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.