Re: Should Globally Needed Objects be Members in Main Frame, Application, or be Global?

From:

David Wilkinson <no-reply@effisols.com>

Newsgroups:

microsoft.public.vc.mfc

Date:

Fri, 01 Sep 2006 11:22:56 -0400

Message-ID:

<#VpN7pdzGHA.1292@TK2MSFTNGP03.phx.gbl>

Tom Serface wrote:

There isn't really. If you want to copy some code from one project to
another it's easy enough to modify the includes. Most of my projects are
pretty stand alone so this works OK for me. If I do have shared code (which
Visual Source Safe is lousy at handling so I try to stay away from doing
this) I just make sure those files don't need any of the project files.

Tom

"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:tq7cf25t485pbvnh63mndtcuf6hprd09vl@4ax.com...

But there should be no reason to include the project file!
joe

On Wed, 30 Aug 2006 09:18:18 -0700, "Tom Serface" <tserface@msn.com>
wrote:

I'm not sure I understand your point. I guess if you mean it's more
difficult to copy from project to project you may be correct in that,
however, I've never found it that difficult to replace the headers for
files
I want to copy. I guess if you wanted to share code you could have
another
header (something like project.h) that you include that would include the
correct project. I think that would make it even more confusing though.

Tom

Tom:

Yes, I have thought of your "project.h" idea, but never got around to
implementing it. Of course "resource.h" is already a generic name, and
is often an adequate substitute for the application header.

But I think the real reason not to include the app header in every
implementation file is that it creates unnecessary compilation
dependency. In a big project, making a change in MyApp.h can kill you.

David Wilkinson