Compilation time penalties incurred(?) by using functor objects instead of functions.
Author
I am facing some problems in organizing my source files...Well, I either have the choice to put non-member functions taking an an object as parameter, in the header file where the "said" object is defined, or writing a class overloading "operator ()" and therefore, put it in its own header file...The benefit of using functor objects is "evident"( they have a state ) besides the OOP paradigm.
The only question I have is: could it incur compilation time penalties, to have, for example, 70 functor objects, each defined in its own source file rather than having corresponding non-member functions defined in the files where their ( object ) parameters are defined?
P.S: sorry for the eventual syntactic or grammatical errors, the English language is not my mother tongue.
If I understand you correctly, what is better: having 70 files that are already compiled and just need to be linked, or having 70 functions implemented in the same file as the main class and need to be all recompiled each time the implementation of the main class changes?
I don't see the connection between whether you have free functions or function objects and where you place the respective declarations/implementations. You can declare and implement several classes in one h/cpp file, or you can place the implementation of all the free functions in separate files.
I don't see the connection between whether you have free functions or function objects and where you place the respective declarations/implementations. You can declare and implement several classes in one h/cpp file, or you can place the implementation of all the free functions in separate files.
Author
Quote:Original post by visitor
If I understand you correctly, what is better: having 70 files that are already compiled and just need to be linked, or having 70 functions implemented in the same file as the main class and need to be all recompiled each time the implementation of the main class changes?
I don't see the connection between whether you have free functions or function objects and where you place the respective declarations/implementations. You can declare and implement several classes in one h/cpp file, or you can place the implementation of all the free functions in separate files.
I know I can, but that wasn't the actual question...
Now it's generally recommended to put in a header file only one class "definition": we all know we can put one thousand class definitions in the same .hpp file, but this is not a practice many people encourage for obvious reasons.
I was asking if having 70 files each containing its own class( Functor ) definition and implementation( template classes in my case ) would make the compilation less fast than having all the ( template )functions implemented as non-member functions in a few files...
Having more files implies having more "#includes" and I wanted to know if it could have an effect on compilation times for a "substantial" number of them. I forgot to mention that almost all my classes are template classes...
On a large project, one of the bottleknecks becomes opening and closing files.
For a REALLY simple demo of this just add 1000 .jpg files to a uncompressed .tar vs adding a single large movie file. It takes longer for the single files.
You'd SAVE on compile time if the functions are subsets of usage patterns. It then becomes useful to only include the template functions in the files that need them.
You'd LOSE on compile time if you end up with something where you are still including all those extra headers all as one group.
For a REALLY simple demo of this just add 1000 .jpg files to a uncompressed .tar vs adding a single large movie file. It takes longer for the single files.
You'd SAVE on compile time if the functions are subsets of usage patterns. It then becomes useful to only include the template functions in the files that need them.
You'd LOSE on compile time if you end up with something where you are still including all those extra headers all as one group.
There is definitely some compile-time overhead to having more files. That being said, when you design in an OO way, there are also other areas that can make the compilation faster by reducing header dependencies. Additionally, with clever use of precompiled headers, you can do a lot to minimize the affect of lots of header files.
My general suggestion is not to worry too much about the additional files unless it starts to become a real burden on compilation. As a C++ developer, unfortunately, there are always tradeoffs for making good and flexible code vs. making code that compiles fast or code that may run a few percentage points faster. My general advice in all of these situations is to go with the more flexible approach, because, just by the nature that it's a flexible approach, you can always refactor back into a less flexible approach. Going the other way is usually much more difficult.
My general suggestion is not to worry too much about the additional files unless it starts to become a real burden on compilation. As a C++ developer, unfortunately, there are always tradeoffs for making good and flexible code vs. making code that compiles fast or code that may run a few percentage points faster. My general advice in all of these situations is to go with the more flexible approach, because, just by the nature that it's a flexible approach, you can always refactor back into a less flexible approach. Going the other way is usually much more difficult.
If you declared ALL your functor objects as references to those objects, then the header file(s) won't even need a definition of those functor objects in question.
Simply declare the class (NOT define) in any header that uses it and you're fine. This may speed things up a little, since you can omit those header files which contain functor object definitions from other header files.
But of course you STILL need to include those functor object definitions into source files, so linking time will largely remain unaffected.
However the trade offs should be good, especially if your compiler supports precompiled headers.
Another trick that's usually deployed for LARGE projects is to split up your code into logical sections... Say graphics, sound, AI etc. You can then compile and link these sections into their own DLLs. Then in the main section, you simply link these DLLs dynamically to the main application.
This 'divide and conquer' approach vastly improves encapsulation (since each DLL is independent), build times (since each DLL is built and linked in separately) and with better modularization, you can reuse such DLLs in future projects.
There are many more advantages to this approach but of course it's not easy to implement, requiring abstract interfaces which adds an extra level of indirection onto the scene (although the performance cost of this is very small).
Just some ideas anyway I'd thought I'd throw into the mix. [smile]
Simply declare the class (NOT define) in any header that uses it and you're fine. This may speed things up a little, since you can omit those header files which contain functor object definitions from other header files.
But of course you STILL need to include those functor object definitions into source files, so linking time will largely remain unaffected.
However the trade offs should be good, especially if your compiler supports precompiled headers.
Another trick that's usually deployed for LARGE projects is to split up your code into logical sections... Say graphics, sound, AI etc. You can then compile and link these sections into their own DLLs. Then in the main section, you simply link these DLLs dynamically to the main application.
This 'divide and conquer' approach vastly improves encapsulation (since each DLL is independent), build times (since each DLL is built and linked in separately) and with better modularization, you can reuse such DLLs in future projects.
There are many more advantages to this approach but of course it's not easy to implement, requiring abstract interfaces which adds an extra level of indirection onto the scene (although the performance cost of this is very small).
Just some ideas anyway I'd thought I'd throw into the mix. [smile]
Author
Quote:Original post by Rydinare
There is definitely some compile-time overhead to having more files. That being said, when you design in an OO way, there are also other areas that can make the compilation faster by reducing header dependencies. Additionally, with clever use of precompiled headers, you can do a lot to minimize the affect of lots of header files.
My general suggestion is not to worry too much about the additional files unless it starts to become a real burden on compilation. As a C++ developer, unfortunately, there are always tradeoffs for making good and flexible code vs. making code that compiles fast or code that may run a few percentage points faster. My general advice in all of these situations is to go with the more flexible approach, because, just by the nature that it's a flexible approach, you can always refactor back into a less flexible approach. Going the other way is usually much more difficult.
Thank you all for your answers...
Actually, I've decided to use only ( template ) object functors instead of non-member functions. It makes it easy to localize code. And as you said, OOP and encapsulation make refactoring very easy as long as the interfaces remain constant.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
