Why do we define functins outsude the class?

This is a discussion on Why do we define functins outsude the class? within the C++ Programming forums, part of the General Programming Boards category; Hi,
I have a little confusion as to yhy do we define functins outsude the class?
This defining of functions ...

It makes for less cluttered code, allows you to see clearly what data types your class contains and their names. Ideally function names should be descriptive, so having the prototypes suffices to grasp what the functions do. If all you want to do is USE the pre-written code, you only need to see the prototypes, ideally.

Some routines get very large, and having a monstrous function written into your class is a pain when you just want to scroll to read to a variable name.

The "::" are not necessarily necessary, so to speak. If you have a function bar outside the class and a function foo inside the class, you just as easily call bar directly from within foo with just bar().
Note that functions may have the same name if they are not within the same namespace. We can easily have a function foo inside the class and a function foo outside the class. In this case, you must specify ::foo() inside the function foo in the class to tell the compiler you mean the function foo outside the class.

Apart from class getting too lengthy because of function definition, can there any other reason to define the function outside of the class?

regards,
Ankit

Originally Posted by Ocifer

It makes for less cluttered code, allows you to see clearly what data types your class contains and their names. Ideally function names should be descriptive, so having the prototypes suffices to grasp what the functions do. If all you want to do is USE the pre-written code, you only need to see the prototypes, ideally.

Some routines get very large, and having a monstrous function written into your class is a pain when you just want to scroll to read to a variable name.

To reduce recompilation times.
Putting them in the cpp file means ofthen only that cpp file needs recompiling.
Also, the more code you put in the header, the more other headers that file probably needs to pull in and thus other files that need to include our header each have to pull in a lot more stuff and take longer to compile.
You want to keep your header file as light as practical.

It's just proper encapsulation. The users of a class should not be interested in seeing or knowing how the class is implemented.

As an extreme example, imagine you're writing a C++ library which you sell to customers. If you put all your code inside the class definitions, then you are exposing all of your source code to whoever buys the library. That is probably NOT cool.

As an extreme example, imagine you're writing a C++ library which you sell to customers. If you put all your code inside the class definitions, then you are exposing all of your source code to whoever buys the library. That is probably NOT cool.

Manasij Mukherjee | gcc-4.9.2 @Arch Linux Slow and Steady wins the race... if and only if :1.None of the other participants are fast and steady.
2.The fast and unsteady suddenly falls asleep while running !

The beauty of headers is that you can declare an interface (read abstract class or pure virtual class) with absolutely no implementation, include it, implement the interface and then clients of your code only need to include the header and a reference to your DLL's import library or dynamically load your DLL and the rest is magic. This allows you the implementor to alter the implementation and not break existing code if you adhere to the interface. In fact you could change your code all day long and as long as it adheres to the interface the client using your DLL never has to be recompiled. This is a huge win when you have tens of thousands of customers in the field using a product and you need to make a small implementation change here or there in a DLL. Forcing all those users to get a new client build not only makes them less than happy (read: angry) but also becomes a huge PITA for the studio. So headers in their purest form usually separate class declaration from class definition which is a godsend when code spelunking to learn a code line or understand its behavior.

Headers at times can be a PITA but that is more a product of MSVS and other IDE's refusal to make it easier to sync up headers with implementation and vice versa than it does the language. Hopefully this will be remedied this by giving C++ programmers the same powerful IDE tools and features that C# has been given and allow us to implement interfaces via a context menu and/or write a dummy C++ implementation for us from a header file. Class wizard does this to some extent (and an ugly extent at that if you look at the output) but the whole thing needs a major overhaul.

Templates aside, IDE's aside, and platform aside, headers, IMO, are one of the nicest things about C++ b/c it allows you to look at an object from a behavioral standpoint without all the confusion of the actual implementation. The header, if written well, will give you very good insight as to what functionality the object offers as opposed to how it offers it.

One reason to never put code in a header is b/c then you will know that when looking at a header you are looking at the object from a bird's eye view as opposed to the nitty gritty implementation. You can put code in headers via inline outside of the class and by simply putting the definition in the class but this clutters the code. Some of the worst code to read is when half the implementation is in the cpp and half of it is in the header. Part of this is due to the fact that MSVS and other IDEs tends to get confused with code that does this and part of it is b/c it becomes annoying switching between the cpp and the header which can cause confusion which will reduce your effectiveness.

I think the best example of why headers are super awesome inventions is to look at C#. To this day I still think C# has some of the ugliest source files I have ever seen in my life. Everything is crammed into one or more files (aka the evil partial classes) and when trying to come up to speed on a code line it is nice to just see the interface or API. Unfortunately in languages that cram everything into one file this is nearly impossible so you are left using the MSVS class explorer which is ok or using the hideous member browser at the top of the file which is nearly useless in most cases. To be fair to C# I should mention you can do the same in C# by simply using interface DLLs but I do not really consider those DLLs since they are really only acting as a C++ header file.

Also your post should read 'Why do we define class member functions outside of the class?'. You can declare and define functions outside of a class in C++ that are not a member of any class. These are very useful as utility functions that can operate on objects without being a member of the objects or any object in the system.

Incidentally there are websites out there that claim headers serve no purpose other than to facilitate the old school linking policy of C. However I vehemently disagree with this statement and believe headers serve a central role in C++ that far surpasses being there just to support a legacy linking process.