where to put headers and cpp files

vendtagain · 03-14-2010, 02:41 PM

I have several classes that I use for multiple programs. Where should I keep the h/cpp files so I only have to add the #include for the compiler to find them?

Sergei Steshenko · 03-14-2010, 02:48 PM

Quote:

Originally Posted by vendtagain

I have several classes that I use for multiple programs. Where should I keep the h/cpp files so I only have to add the #include for the compiler to find them?

I'd suggest having a directory per class. And, consequently, to write something like

Code:

#include "YourProjectName/ClassName/FileToBeIncluded"

.

I.e also have 'YourProjectName' component.

vendtagain · 03-14-2010, 02:54 PM

The files should not actually be with any certain project, as it will be used by multiple projects. I am thinking a place like /opt/local/className/ , but I'm not sure about the paths the compiler uses to find them. And also so I don't have to add the cpp file. Just like using a standard library, but instead of #include <string> it would be #include "myclass.h"

Sergei Steshenko · 03-14-2010, 03:55 PM

Quote:

Originally Posted by vendtagain

The files should not actually be with any certain project, as it will be used by multiple projects.
...

O course ! You change a file used by a number of projects, you make a mistake, you screw a number of projects simultaneously.

Never assume you won't make a mistake, never assume your changes won't cause regressions.

I am persistently and sadly amused by, for example, ALSA - they change something in files used by a number of card drivers and suddenly new ALSA release makes card that used to work non-functional under ALSA. ALSA users list is full of such complaints.

Another recent example - I routinely build 'glib' and 'wxGTK' - the latter depends on the former.

wxGTK-2.8.10 builds fine with glib-2.20.5, but not with glib-2.22.2 - the latter breaks wxGTK-2.8.10 'make', even though 'configure' is OK.

So, I've built glib-2.22.2 and built wxWidgets-2.9.0 - the latter is OK with glib-2.22.2. Am I happy now ? Not quite - the latest wxMaxima-0.8.4 which depends on wxWidgets builds just fine with wxGTK-2.8.10, but not with wxWidgets-2.9.0. So I can't build wxMaxima-0.8.4 at the moment easily (yes, my build tool allows to have a number of versions of the same library simultaneously, but it increases my effort to describe dependencies).

So, you see what mess was caused by upgrade from glib-2.20.5 -> glib-2.22.2 ?

No, a reasonable person should ask me why I violated "if it ain't broken, don't touch it" principle ? Quite a legitimate question. Well, the answer is simple: I need to build libsoup-2.28.2 which happens to depend on 'glib', and glib-2.20.5 is too old for it. And I can live without 'wxMaxima' for time being.

paulsm4 · 03-14-2010, 04:11 PM

vendtagain -

If I were you, I'd probably put these headers in a "common/" or "util/" directory parallel to your other projects. For example:

Code:

  /home/myhome/myprojects/projecta/*
  /home/myhome/myprojects/projectb/*
  /home/myhome/myprojects/common/*

You already know the importance of the '#include "myheader.h"' syntax (vs. '#include <systemhdr.h>'); and I assume you know about the -I and -L gcc switches (to specify header- and library directories).

So you should be set!

And yes, arguments can be made for putting the headers in different places (e.g. "/usr/local/mycommon", or perhaps even "/opt/mycommon"). And I don't completely disagree with Sergei Steshenko that *any* "common headers" are potentially a bug waiting to happen.

But frankly, I think the DRY principle takes precedence.
That's exactly what you're trying to accomplish here and I applaud you.

IMHO .. PSM

Sergei Steshenko · 03-14-2010, 04:41 PM

Quote:

Originally Posted by paulsm4

...
But frankly, I think the DRY principle takes precedence.
That's exactly what you're trying to accomplish here and I applaud you.

IMHO .. PSM

Yes, just to reiterate what's already been said - I agree with the DRY principle, but from experience I also know that allowing somebody else to be authoritative source of ever mutating knowledge is a source of disaster.

I.e. I believe that "single point of change" principle in which I strongly believe should be tightly combined with "no unexpected changes by others and no moving targets chasing".

vendtagain · 03-14-2010, 05:37 PM

Quote:

Originally Posted by paulsm4

vendtagain -

If I were you, I'd probably put these headers in a "common/" or "util/" directory parallel to your other projects. For example:

Code:

  /home/myhome/myprojects/projecta/*
  /home/myhome/myprojects/projectb/*
  /home/myhome/myprojects/common/*

You already know the importance of the '#include "myheader.h"' syntax (vs. '#include <systemhdr.h>'); and I assume you know about the -I and -L gcc switches (to specify header- and library directories).

So you should be set!

And yes, arguments can be made for putting the headers in different places (e.g. "/usr/local/mycommon", or perhaps even "/opt/mycommon"). And I don't completely disagree with Sergei Steshenko that *any* "common headers" are potentially a bug waiting to happen.

But frankly, I think the DRY principle takes precedence.
That's exactly what you're trying to accomplish here and I applaud you.

IMHO .. PSM

Just what I was looking for.

Quote:

Originally Posted by Sergei Steshenko;

O course ! You change a file used by a number of projects, you make a mistake, you screw a number of projects simultaneously.

Never assume you won't make a mistake, never assume your changes won't cause regressions.

Appreciate the tips, though most of the classes I will be using here are fairly simple. And I tend to keep multiple backups as well.

paulsm4 · 03-14-2010, 06:35 PM

Hi -

Two very effective ways you can mitigate against "unexpected changes" are:

a) Create simple, automated unit tests for all of your client code
Get in the habit of running your tests asa standard part of your build procedure

b) If you ever need to change an interface ... don't!
Instead, whenever/wherever possible, create a *new* interface:

EX: myinterface(int parm1, int * parm2)
myinterface2(int parm1, int *parm2, const char *parm)
<= Think "interfaces are immutable"
It'll make your client code much easier ;-)

IMHO .. PSM

Sergei Steshenko · 03-15-2010, 08:42 AM

Quote:

Originally Posted by paulsm4

Hi -

Two very effective ways you can mitigate against "unexpected changes" are:

a) Create simple, automated unit tests for all of your client code
Get in the habit of running your tests asa standard part of your build procedure

b) If you ever need to change an interface ... don't!
Instead, whenever/wherever possible, create a *new* interface:

EX: myinterface(int parm1, int * parm2)
myinterface2(int parm1, int *parm2, const char *parm)
<= Think "interfaces are immutable"
It'll make your client code much easier ;-)

IMHO .. PSM

In "my" VLSI world there was no release without tests. It was my job to develop and maintain verification environment and to run regression tests. At all, in VLSI world tests are being run 24/7, nowadays tests are mostly random.

Still, the methodology was to have everything under control, for example, both the VLSI design and the simulation/verification environment were in one tree.

Never there were releases without tests. Individual designers were allowed to submit their stuff into the project tree only after running a reasonable subset of regression tests.

Sergei Steshenko · 03-15-2010, 08:50 AM

Quote:

Originally Posted by paulsm4

Hi -

...

b) If you ever need to change an interface ... don't!
...

IMHO .. PSM

Suppose you had a function:

Code:

#define K 0.123
double f(double x)
  {
  return K * x;
  }

And then somebody decided that K should better be 0.456 - no interface change whatsoever, but those who counted on old behavior of 'f' are screwed.