Multiple cpp files
Author
I have seen numerous programs (like the doom source which I just downloaded) which use multiple .cpp and .h files. What is the benefit to having more than 1 .cpp file, and how do you implement using more than one?
Do you just create it as one project, and then the compiler pretty much thinks of it as one big .cpp file, so that the only reason its split up is for readability?
Organizational reasons more than anything. Its always better to encapsulate relevant objects seperatly.
The simple (but not 100% correct) answer:
Yes, split things up into multiple cpp & h files for readability. Try the JAVA approach. Each class should have its own cpp & h file.
Trust me, when you start getting 100000 line programs, having only 1 file will make it very difficult to read.
As for implementing more than 1, just link them together. Any makefile tutorial should help you out on this.
Yes, split things up into multiple cpp & h files for readability. Try the JAVA approach. Each class should have its own cpp & h file.
Trust me, when you start getting 100000 line programs, having only 1 file will make it very difficult to read.
As for implementing more than 1, just link them together. Any makefile tutorial should help you out on this.
The only real benefit is to the programmer and/or team. It allows you to sort things out for easier access. Like one file may contain code that deals with just weapons. And another for enemies. Otherwise, you could just slap it all in one file. Damn, that would be one long file.
If you change just a single thing in a gigantic cpp file, the whole world is getting recompiled and you might as well go take a nap. If you split your project into multiple translation units (and you have to be smart about it too, like using the pimpl idiom), you can mitigate the long recompilation problem.
Quote:Original post by c-gibson-sPrivate implementation idiom, in which your published interface depends on a private implementation which may change between versions. This insulates your users from radical change.
pimpl?
Private to IMPLementation, a.k.a Bridge Pattern. A technique that insulate client code from changes in the private implementation of a class by adding an extra layer of indirection.
Foo.h
Foo.cpp
FooImpl.h
FooImpl.cpp
If you change an implementation in FooImpl.cpp, that's all you have to recompile.
If you change a private member in FooImpl.h, you only have to recompile FooImpl.cpp and Foo.cpp
ONLY if you change a public member in Foo.h (and FooImpl.h) does code using the Foo class need to be recompiled.
No code using Foo ever needs to see FooImpl's details.
Foo.h
class FooImpl;class Foo{ FooImpl* impl;public: Foo(); ~Foo(); void SomePublicFunction(); };Foo.cpp
#include "Foo.h"#include "FooImpl.h"Foo::Foo(): impl(new FooImpl){}Foo::~Foo(){ delete impl;}void Foo::SomePublicFunction(){ impl->SomePublicFunction();}FooImpl.h
class FooImpl{ int some_private_variable; void SomePrivateFunction();public: void SomePublicFunction();};FooImpl.cpp
#include <iostream>#include "FooImpl.h"void FooImpl::SomePrivateFunction(){ ++some_private_variable;}void FooImpl::SomePublicFunction(){ SomePrivateFunction(); std::cout << some_private_variable << std::endl;}If you change an implementation in FooImpl.cpp, that's all you have to recompile.
If you change a private member in FooImpl.h, you only have to recompile FooImpl.cpp and Foo.cpp
ONLY if you change a public member in Foo.h (and FooImpl.h) does code using the Foo class need to be recompiled.
No code using Foo ever needs to see FooImpl's details.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement