Programming

I have three directories CspInterp, FpnInterp and LinInterp.
Each directory contains 4 .h and .ccp files describing 4 classes each

CspInterp
class CspFsInterp1d : public FsInterp1d
class CspVsInterp1d : public VsInterp1d
class CspFsInterp2d : public FsInterp2d
class CspVsInterp2d : public VsInterp2d

FpnInterp
class FpnFsInterp1d : public FsInterp1d
class FpnVsInterp1d : public VsInterp1d
class FpnFsInterp2d : public FsInterp2d
class FpnVsInterp2d : public VsInterp2d

LinInterp
class LinFsInterp1d : public FsInterp1d
class LinVsInterp1d : public VsInterp1d
class LinFsInterp2d : public FsInterp2d
class LinVsInterp2d : public VsInterp2d

They are derived from four other classes, each of them also being derived
from two classes

class FsInterp1d : public Interp1d
class VsInterp1d : public Interp1d
class FsInterp2d : public Interp2d
class VsInterp2d : public Interp2d

Each class is coded in its respective .h and .cpp

I need some help on a good way to organize this code for eventually creating a large scale C++ project. I am currently putting things in several directories depending on their topic. The ones shown here are for 1d- and 2d-interpolation using Linear, Fourier Polynomials, and Cubic Splines.

How you organize source files often depends on -- and is constrained by -- how you must compile and link them.

I've seen projects where each little class gets its own separate folder and makefile. These tend to be slow to compile due to all the recursive makes calling makes, and the include paths can be horrendously complex. I don't recommend this model.

On the other end of the scale, I've seen projects where the header files are all lumped in one general include/ folder, and the source files organized by folder. This lets you feed -I ./include into $(CC) and mostly forget about headers. Sometimes you see folders inside the ./include/, and files included like #include <subfolder/subtype.h>. Sometimes you see local .h files in the same source folders as the .c/.cpp files included by #include "localheader.h" alongside header files in a global ./include/ which get included by a #include <globalheader.h> This might be less useful in C++ than C, since C can get away with local-only types and undefined types a lot of times C++ classes can't.

I've also seen projects which are organized into sub-libraries internally, compiled separately and linked in with additions to include and library paths. This is sort of like the first strategy, but with many source files and headers per project instead of few. It helps compartmentalize things while reducing the amount of headaches from enormous path lists and recursing recursion...

It might be useful to really break it up into separate libraries, too. I've often found large applications to be full of things which should have been libraries, being useful in other contexts or easily replacable by standard equivalents, but weren't... Sometimes that's the only thing which makes a 'large' application 'large'...

It's much easier to compartmentalize a C library than a C++ one. It's also much easier to bind C code than C++ code into other languages. This is why you'll often find libraries written in pure C, and C++ template wrappers to turn them into classes for people who want them.

I do need to separate them into some folders (although not too many) instead of having all the code in just one directory. I would want the .ccp and .h files in the same location as well, rather than having the .h in a separate headers folder. I currently have one makefile.

My only problem is where to put the base classes for the interpolation.

CspInterp
class CspFsInterp1d : public FsInterp1d
class CspVsInterp1d : public VsInterp1d
class CspFsInterp2d : public FsInterp2d
class CspVsInterp2d : public VsInterp2d

FpnInterp
class FpnFsInterp1d : public FsInterp1d
class FpnVsInterp1d : public VsInterp1d
class FpnFsInterp2d : public FsInterp2d
class FpnVsInterp2d : public VsInterp2d

LinInterp
class LinFsInterp1d : public FsInterp1d
class LinVsInterp1d : public VsInterp1d
class LinFsInterp2d : public FsInterp2d
class LinVsInterp2d : public VsInterp2d

Up till here is ok, but then I am left with the following base classes

class FsInterp1d : public Interp1d
class VsInterp1d : public Interp1d
class FsInterp2d : public Interp2d
class VsInterp2d : public Interp2d
class Interp1d
class Interp2d

Base headers, at least, should be somewhere generic -- everything needs them. Put them in ./include/, or just leave them in your root folder.

Really though, generic headers don't belong with your source, that's why they're separate files -- for the convenience of other code using it. They need to be easy to find, and traditionally get lumped in one include dir.

If there's bits in your headers that don't make sense for everything to include, separate them out into private header files for your classes, leaving the generic bits to go into ./include/. Only the bits needed to use the class belong in ./include/, things to help define it should be internal.

Of course this all goes out the window if you use templates. Then it's real hard to have an opaque anything.

I do have some templates as well for performing complex number arithmetic which I have put under directory math.

If a class uses a templated object as any part of its interface, anything that uses the class header needs the template header. So that might as well be in the generic ./include/ too.

That's so you can include <filename.h> without worrying whether it has to be a <../math/filename.h>, <../../../lib/math/filename.h>, <path/to/filename.h>, "/home/username/code/c/project/math/filename.h" or what have you. You'd be surprised at the lengths people go to, to avoid having an organized include folder...

Do people actually do <path/to/filename.h> when using directory structures to separate the various parts?