My sourcecodes are getting longer and longer so harder to correct (modify). I know that a part of the code (some functions) are correct. How can I break the code into several files?
What can I do else?
Printable View
My sourcecodes are getting longer and longer so harder to correct (modify). I know that a part of the code (some functions) are correct. How can I break the code into several files?
What can I do else?
use .h files for declarations.
use .cpp files for definitions.
include the .h files in the .cpp files where the functions are needed using #include
get it?
>My sourcecodes are getting longer and longer so harder to correct (modify).
Should not be.
>How can I break the code into several files?
You can distribute your code over several source-files and header-files. If you do this in a handy way, you can reuse your code by just using the created files. I don't know which compiler you use, but I guess there is a possibility of making a make-file or project-file to maintain projects consisting of more than one source-file.
Object-oriented design is a great way to get going though still does not always guarantee "proper" organization. If you're not using objects, then you might want to start, if not, then it helps to at least think of your code as objects (even if you don't implement them as such).
Try to separate yourself from your code for a second and think about your project on a higher level. Think in abstract terms what your project is. I always use a game as an example because it's easier to see breakdowns and games are a great example of where most people can see why objects make sense, but the same logic carries through to any application.
Usually you can say "well... my program has players... levels... enemies... etc."
An example on how you might want to set up multiple files for that project would be
Have a header and a source file for everything associated with the player, a header and a source file for everything associated with levels, a header and a source file for everything associated with the enemies, etc.
In general, each source file should be paired with a header file, but you might want to make multiple source files for the same header file if you have a lot of declarations within the header.
So, try to make a header for each collection of "like concepts" that contain class definitions and source files to go along with them. A lot of places will tell you to make a separate header for each class definition but, in my opinion, a purely object-oriented project that tends to result in a huge amount of files which can be counterproductive (IE I'm not even past the core of the engine of my current project but it already has over 100 classes). A separate header file for each tends to actually make things harder to deal with, but again, that's just my opinion.
In my projects I always put classes in C++ or modules in C in seperate files, which makes it easier for reuse in other projects. I have not noticed this to be counterproductive, since a lot of classes and modules already tested don't require maintanance.Quote:
(..) but, in my opinion, a purely object-oriented project that tends to result in a huge amount of files which can be counterproductive (..) A separate header file for each tends to actually make things harder to deal with, but again, that's just my opinion.
What reasons would you give to cause this way of development counterproductive?
I'd rather look through one file that has 3 or 4 related audio class definitions that I will most likely be working with at the same time than having them all in separate files that I have to switch back and forth between. I knew some people would disagree, but that's how I prefer to deal with my applications. Having 100 separate files for 100 separate classes doesn't exactly seem like organization -- that just switches the need for organization from class definitions to files.Quote:
In my projects I always put classes in C++ or modules in C in seperate files, which makes it easier for reuse in other projects. I have not noticed this to be counterproductive, since a lot of classes and modules already tested don't require maintanance.
What reasons would you give to cause this way of development counterproductive?
Reuse in other projects is just as easy. The ones you group are the ones that you'd put in the same library and be using with each other anyways.
Thank you everybody. It worked both with header files and several cpp files.