How to organize these code?
Hi guys,
I am planning use boost or Qt library. Not both in one compilation but both in one repository:
C++ files will categorized:
1. Files related to boost - iterations over directories, mapping files
2. The same related to Qt
3. Files independent from this both: for example analyse data, no matter that array of bytes is in memory or mapped file..
Thanks for any help!
I am planning use boost or Qt library. Not both in one compilation but both in one repository:
C++ files will categorized:
1. Files related to boost - iterations over directories, mapping files
2. The same related to Qt
3. Files independent from this both: for example analyse data, no matter that array of bytes is in memory or mapped file..
Thanks for any help!
Well three appropriately named sub-directories to match the three concepts you have at the moment would be a start.
Or maybe just the one directory containing everything until the partitioning becomes clearer. It might be the best place to start if you've only got a handful of source files outlined so far.
Moving a source file from one directory to another is relatively simple.
Teasing out a mish-mash of unrelated functionality from a single source file into multiple sources for different themes is considerably harder.
The important thing is to keep your internal interfaces clean, and each source file performing a clear task.
Or maybe just the one directory containing everything until the partitioning becomes clearer. It might be the best place to start if you've only got a handful of source files outlined so far.
Moving a source file from one directory to another is relatively simple.
Teasing out a mish-mash of unrelated functionality from a single source file into multiple sources for different themes is considerably harder.
The important thing is to keep your internal interfaces clean, and each source file performing a clear task.
I prefer to divide my files based on which standard headers they access. If the headers start with letters a-m, the files go in one directory. If the headers start with n-z, the files go in another directory. So for example, I never have a file that #includes both <algorithm> and <vector>
...
I'm joking of course. I hope you see that this would be a really horrible way to organize files. It's an arbitrary classification. To follow it, I'd have to break the code up in strange, hard to follow ways. And doing some simple things might be impossible (like sorting a vector: std::sort is in <algorithm> and std::vector is in <vector> ).
I think your desire to divide the files into those that use boost and those that use Qt is similar.
Divide your files along functional boundaries.
...
I'm joking of course. I hope you see that this would be a really horrible way to organize files. It's an arbitrary classification. To follow it, I'd have to break the code up in strange, hard to follow ways. And doing some simple things might be impossible (like sorting a vector: std::sort is in <algorithm> and std::vector is in <vector> ).
I think your desire to divide the files into those that use boost and those that use Qt is similar.
Divide your files along functional boundaries.
Last edited on
As I said, I usually divide my code along functional lines, which usuall translates into class lines. So each class has a header file and an implementation file. There's also a file for the main program, usually called progname.cpp where progname is the name of the executable.
And as the pirates say, these are more like guidelines. In school assignments, where programs are small, you might put multiple classes in one file. At work we sometimes split classes into multiple files. Sometimes because the class is just big. Sometimes because a method is seldom used and causes the linker to bring in tons of other code. You get the idea.
One trick for the professional world, if a method isn't in the "normal" source file, add a comment to the normal file with the method name and saying where it is. That way if someone goes looking for it, they'll know where it is. This might not be necessary with modern development environments.
And as the pirates say, these are more like guidelines. In school assignments, where programs are small, you might put multiple classes in one file. At work we sometimes split classes into multiple files. Sometimes because the class is just big. Sometimes because a method is seldom used and causes the linker to bring in tons of other code. You get the idea.
One trick for the professional world, if a method isn't in the "normal" source file, add a comment to the normal file with the method name and saying where it is. That way if someone goes looking for it, they'll know where it is. This might not be necessary with modern development environments.
...but it is still a good idea. That, and there should be a good, documented reason why the method is not defined in the expected place.
Since this is probably going over OP’s head, what we are talking about is this:
Given a module (say, defining a class you wrote), there should typically be two files associated with it: the header and the implementation. So the
quux.hpp — all the declarations and inline methods
quux.cpp — all the non-inline methods and static data
There do exist times where this is not sufficient, but such cases are (and should be) Rare, with a capital ‘R’. If you look in quux.hpp and find a method of the Quux class, you can expect to find the method’s definition in the quux.cpp file. If it is NOT there, you are either making a mistake or there is a very, very good and well-documented reason why not (at least, there should be).
Heh...
Since this is probably going over OP’s head, what we are talking about is this:
Given a module (say, defining a class you wrote), there should typically be two files associated with it: the header and the implementation. So the
Quux class should be defined in the files:quux.hpp — all the declarations and inline methods
quux.cpp — all the non-inline methods and static data
There do exist times where this is not sufficient, but such cases are (and should be) Rare, with a capital ‘R’. If you look in quux.hpp and find a method of the Quux class, you can expect to find the method’s definition in the quux.cpp file. If it is NOT there, you are either making a mistake or there is a very, very good and well-documented reason why not (at least, there should be).
Heh...
Last edited on
| Niccolo wrote: |
|---|
| Anyone notice that @levithanh425 hasn't participated in two days? |
Funny that:
http://www.cplusplus.com/forum/general/255305/#msg1119425
Somebody's playing silly games.
Last edited on
| Niccolo wrote: |
|---|
| Anyone notice that @levithanh425 hasn't participated in two days? |
Situation Normal. Give it a week or so.
If curious, you can google around and see if OP is getting “help” more to his liking on another forum. (Also Situation Normal.)
Last edited on
Topic archived. No new replies allowed.