Elysian Shadows

Ok, I haven't programmed in C++ in awhile and am picking it up again having spent the last several years working in C#.

When I originally took my undergrad classes, we would split a class into a header file and an implementation file. Is this still the norm or have things progressed to a new standard?

mattheweston wrote:Ok, I haven't programmed in C++ in awhile and am picking it up again having spent the last several years working in C#.

When I originally took my undergrad classes, we would split a class into a header file and an implementation file. Is this still the norm or have things progressed to a new standard?

That's how C++ works. Nothing has changed.

ok, I know some people combine them now and I was curious as to if there was any performance increase by doing so or if it was mearly a matter of preference.

mattheweston wrote:ok, I know some people combine them now and I was curious as to if there was any performance increase by doing so or if it was mearly a matter of preference.

• Templates must always be implemented in a header. The one and only exception to this rule is when you're completely specializing a template--then it can be declared in a header and defined in a source file.
• You usually only want to implement functions in a header when they're really simple and need to be called frequently. They need to be declared as explicitly inline, otherwise they will be compiled into every source unit that includes the header, and you'll get multiple definition linker errors.
• The same for functions applies to class methods. However, they do not need to be explicitly inlined--the compiler will automatically inline them. Good examples of methods you might want to implement in a header are pass-through mutators and accessors that don't do any additional processing on the data.

Another thing to take into account when deciding whether or not a function should be inlined is the number of #includes it requires. Adding unnecessary includes to a header for an inline function will increase compile time. If you have a function that takes and returns a std::string, but uses <algorithm>, <functional>, and <cctype>, you should put it in a source unit and only include <string> in the header.

There are probably a few more rules of thumb, but these are the main ones. Also note that these are just my personal views which I have found to work quite well. As such, I don't have any source to cite.

Do you have a website url handy where I might find a list of the "rules of thumb" or do I just search "rules of thumb" and C++?

mattheweston wrote:Do you have a website url handy where I might find a list of the "rules of thumb" or do I just search "rules of thumb" and C++?

I do not. I should've clarified that these are my own personal rules, with the exception of the first one--that is fact. I've edited my original post to state this. You can, however, probably find more information elsewhere on the Internet. Hit no. 3 for "c++ rules of thumb" on Google reveals this post on StackOverflow which contains a lot of useful wisdom.

Well honestly the format i use which may not exactly be the best is that i put all my classes in 1 header, all my defines in one header, and have the rest in main.cpp, probably not the best idea but hey it works for me.

Light-Dark wrote:Well honestly the format i use which may not exactly be the best is that i put all my classes in 1 header, all my defines in one header, and have the rest in main.cpp, probably not the best idea but hey it works for me.

Definitely not the best. Besides being difficult to organize (and being a generally massive file), it also slows down your build because the compiler is re-preprocessing, parsing, and compiling that huge file every time you change a single character. By splitting your code across multiple files, the compiler only has to recompile each (small) file that changed (or had its dependencies changed), and then re-link everything (or just the objects that changed if your linker supports incremental linking).

If it works for you and you are aware of the implications, keep at it, I guess. If you ever share your code (or work on a team), however, you might want to give some serious consideration to giving each class its own file, grouping things in files logically, etc. It'll make it substantially easier for someone who is new to your codebase to orient themselves and get a feel for things.

Nokurn wrote:

• Templates must always be implemented in a header. The one and only exception to this rule is when you're completely specializing a template--then it can be declared in a header and defined in a source file.

Another thing to take into account when deciding whether or not a function should be inlined is the number of #includes it requires. Adding unnecessary includes to a header for an inline function will increase compile time. If you have a function that takes and returns a std::string, but uses <algorithm>, <functional>, and <cctype>, you should put it in a source unit and only include <string> in the header.

There are probably a few more rules of thumb, but these are the main ones. Also note that these are just my personal views which I have found to work quite well. As such, I don't have any source to cite.

Just as a note on a template point. I believe in C++x0(whatever) you can have the declaration and definition in different files.

as for inline, be careful with this one. firstly, declaring a function as inline is basically just asking the compiler to take this code and place it directly where the "call" happens, it does not mean it will happen, because of this it introduces some issues when you want to debug code. Most compilers do a fine job of inlining functions automatically if I recall. if you do inline something, make sure its only a small piece of code. also be weary of recursion when explicitly hinting for inline.

think of inlining as a macro.

Nokurn made a great comment on includes and compile times, this is a topic to pay close attention to if you are going to be working on large projects. if you have a header that is included in 90 percent of your code, and you change 1 line in your header, all files including it will have to be recompiled.

anyways, Nokurn made some good points.

avansc wrote:Just as a note on a template point. I believe in C++x0(whatever) you can have the declaration and definition in different files.

C++ already does this, as long as the definition is in a file that is available to the file where it's being instantiated (ie. in a header). I think what you're referring to is C++11's "extern templates" feature. Extern templates don't really change the requirements of template definition availability. They're more of a compile time optimization that you can add to your code by explicitly declaring a template instantiation to be done externally, then instantiating it in a source file, so that the compiler only instantiates the template once. Wikipedia and Stroustrup have more info.

avansc wrote:anyways, Nokurn made some good points.

Thanks.

mattheweston wrote:Do you have a website url handy where I might find a list of the "rules of thumb" or do I just search "rules of thumb" and C++?

I might be alittle late, but this site is good:
http://geosoft.no/development/cppstyle.html
you need not follow it entierly, but it has great arguments for how to structure things

Light-Dark wrote:Well honestly the format i use which may not exactly be the best is that i put all my classes in 1 header, all my defines in one header, and have the rest in main.cpp, probably not the best idea but hey it works for me.

I mean no offense, but that is an absolutely terrible paradigm to be using.

You are going to wind up with two gigantic header files that contain everything, and every .cpp file having to include each one of those... that's a gigantic amount of overhead for .cpp files that only need a class or two. Your build times are going to be awful.