c++ project structures

  • Thread starter Thread starter dotnetchic
  • Start date Start date
D

dotnetchic

Okay, it's been a while since I've managed large projects in vs c++.
So I've got a project structure question.

I have about 5 projects that I am bringing into MC++ VS2005 (from VS
6). I've got 2 of these projects converted, compiled, and running so
far. But all 5 of the projects share some of the code, in a way that
needs to be changed.

Right now, each project contains code files within its project
directory. So if I make a change to codefile1.cpp or codefile1.h that
is shared across all 5 projects, I have to make that change across ALL
FIVE PROJECTS. What I would like to do is move these out to a common
shared directory and have one solution that includes all the projects,
but I still want to use relative path names on my includes. (My
initial attempt at this forced me down a route to explicity label the
path that the include file was in, which is NOT what I want).

Obviously, I need a little direction.
 
dotnetchic said:
Right now, each project contains code files within its project
directory. So if I make a change to codefile1.cpp or codefile1.h that
is shared across all 5 projects, I have to make that change across ALL
FIVE PROJECTS. What I would like to do is move these out to a common
shared directory and have one solution that includes all the projects,
but I still want to use relative path names on my includes. (My
initial attempt at this forced me down a route to explicity label the
path that the include file was in, which is NOT what I want).
Click to expand...

In these cases my configuration is usually: all shared files are in
$(SolutionDir), all projects are in separate folders under
$(SolutionDir), all project specific files are in theirs $(ProjectDir),
and for all projects and all configurations add
"$(SolutionDir);$(ProjectDir)" in Additional Include Directories.

Having all files have unique names is a requirement.
 
Mihajlo said:
In these cases my configuration is usually: all shared files are in
$(SolutionDir), all projects are in separate folders under
$(SolutionDir), all project specific files are in theirs $(ProjectDir),
and for all projects and all configurations add
"$(SolutionDir);$(ProjectDir)" in Additional Include Directories.
Click to expand...

How will this configuration affect my precompiled headers? If I keep
the precompiled headers in the main directory (or in the search path)
will that suffice?

Thanks,
Sharon
 
dotnetchic said:
How will this configuration affect my precompiled headers? If I keep
the precompiled headers in the main directory (or in the search path)
will that suffice?
Click to expand...

Precompiled header is just an ordinary header that has only performance
related special meaning to the compiler. I use precompiled headers w/o
problems. Of course when you rearrange source files you'll need to do a
full rebuild.

On the second thought, if you #include a project specific header in the
precompiled header I don't know what would happen, but you shouldn't be
doing that anyway. Only things that don't change in project compilation
can/should be precompiled.
 
Mihajlo said:
On the second thought, if you #include a project specific header in the
precompiled header I don't know what would happen, but you shouldn't be
doing that anyway. Only things that don't change in project compilation
can/should be precompiled.
Click to expand...

Yes, there are project-specific headers included in the precompiled
headers. These projects have had no central management nor source
control in place before I got here...I'm afraid I'm in for a large
clean-up. Just want to make sure I follow standards while doing it.

Thanks,
Sharon
 
dotnetchic said:
Yes, there are project-specific headers included in the precompiled
headers. These projects have had no central management nor source
control in place before I got here...I'm afraid I'm in for a large
clean-up. Just want to make sure I follow standards while doing it.
Click to expand...

I have played a bit with this "project specific stuff in stdafx.h"
thing, and managed to make it work. One solution (Test), two projects
(Test1 and Test2), and #include "project_specific.h" within stdafx.h. In
Test1\project_specific.h there's a line

static const int number = 1;

and in Test2\project_specific.h it's "= 2;". In Test1's main() there's

cout << "1 = " << number << endl;

and in Test2 there's "2 = ". When Test1 is run the result is "1 = 1",
and when Test2 is run the result is "2 = 2".

You need to remove existing stdafx.* from both projects, put files
stdafx.cpp and stdafx.h to Test folder, add them to both Test1 and Test2
projects, set stdafx.cpp PCH option in both projects to "Create
Precompiled Header", and add $(ProjectDir);$(SolutionDir) to both
projects in "Additional Include Libraries". It's easier to do it than to
explain it :)

The conclusion is that it can be done, if you're careful enough.
 
dotnetchic said:
Okay, it's been a while since I've managed large projects in vs c++.
So I've got a project structure question.

I have about 5 projects that I am bringing into MC++ VS2005 (from VS
6). I've got 2 of these projects converted, compiled, and running so
far. But all 5 of the projects share some of the code, in a way that
needs to be changed.

Right now, each project contains code files within its project
directory. So if I make a change to codefile1.cpp or codefile1.h that
is shared across all 5 projects, I have to make that change across ALL
FIVE PROJECTS. What I would like to do is move these out to a common
shared directory and have one solution that includes all the projects,
but I still want to use relative path names on my includes. (My
initial attempt at this forced me down a route to explicity label the
path that the include file was in, which is NOT what I want).

Obviously, I need a little direction.
Click to expand...

A couple thoughts of my own -

First, I'd avoid shared files like the plague, with the exception of header
files that define the public (only!) interface to libraries. If you have
non-header source files that are shared, the solution needs to be refactored
to move those modules into a library or DLL of their own.

Second, the definitive work on the subject is this one:
http://www.amazon.com/gp/product/0201633620

-cd
 
Carl said:
First, I'd avoid shared files like the plague, with the exception of header
files that define the public (only!) interface to libraries. If you have
non-header source files that are shared, the solution needs to be refactored
to move those modules into a library or DLL of their own.

Second, the definitive work on the subject is this one:
http://www.amazon.com/gp/product/0201633620

-cd
Click to expand...

There are non-header source files, and I had considered creating
libraries
for them...problem is, they don't lend themselves to any clear
organization. Could just lump them all into some "common" library, but

it doesn't feel right. There are IO functions, graphics display
functions,
security functions, and the list goes on. I'm thinking since there is
so
much common functionality, we instead have one application focused on
our core product and include the several other projects as tools.

Thanks for the info.
Regards,
Sharon
 
Back
Top