The problem I have is that I have a workspace with two projects in it. One is all of my game code, and the other is an MFC diagnostic tool I'm building for the game. I want the tool to include in its build the source files from the game project, but I don't want two copies of source floating around in two different places. I want to keep them organized by project. What I tried doing is setting the game project to be a dependent project of the tool. However I get LNK2001 errors saying it can't find the parts of my game engine I use in the tool, and it ends with LNK1120. I think part of the problem is that the .cpp files reference a relative path of the .h for my classes, and the game code classes are in a different directory than the tool code. So I tried telling the tool project to use the .obj files generated from debug builds of the game, but then I got many errors, among them ones that operators new and delete are already defined. I also tried adding additional include paths to the project settings -> C/C++ tab -> PreProcessor category, but that did not work. I guess I'm looking for something I haven't tried yet, or to know if I'm even going about this the right way. Thanks in advance! [Edited by - MajorShredd on November 9, 2008 8:35:05 PM]

If your game project produces an exe, I don't think adding it as a dependency will link the code like a library. Your best bet is to separate all shared code into another static library project, and then have both the game and tool projects use that. Make sure the game's WinMain function is not part of that shared code.

You realize VC6 is a decade old, obsolete, and a terrible C++ compiler, right?

I hope you didn't pay too much for it. I didn't even think anyone sold it anymore.

VC2008 is available, and is light years better. And it's free.

And nobody uses MFC anymore either. You sure like abysmal tech ;)

Quote:Original post by RDragon1
You sure like abysmal tech ;)

Awww. I was going to say that after he made his changes :)

I fully expected to get grilled on this thread :)

I don't suppose I have the luck that a grizzled veteran would come along and read it. As a postmortem, I found an include path option independent of specific projects that worked for what I wanted.

On a lighter note, I've had my copy that long and it serves me fine for as infrequently as I have had to use it. And be fair now, there are still installed code bases in the wild running on MFC.. those bases are probably also running on a PII with Windows 98. Poor users :) As it happens I may have to work in one such base at my next job. Legacy coders can make serious bank slogging mud all day! I knew a guy that easily made middle six figures for a few months maintaining a COBOL base, knowing full well after he was done they were going to kick him. But hell, why not tuck away the extra trimmings after paying your monthlies into some nice investments? :)

Yes, VC++ 6.0 might be used for legacy purposes as you say. However, be aware that VC++ 6.0 was released before the C++ standard, and as such it does not follow the C++ standard (which is why using it is discouraged here). So if you want to write modern C++ code, make sure to upgrade to something more recent, or you will run into problems.

I think you`re all making too much mess about VC6. I still use it at home for all of my home game projects and it works just fine. Yeah, it`s not exactly standard-compliant but does the end user care ? Hardly.

However, you`re wrong about VS2008 being free. It`s not if you need to maintain your MFC dialogs, which you need to pay for in Standard version.

How is it free if I am to completely redesign/rewrite all UI stuff for my editor ? That time can be hardly declared as free, since it`s going to cost me lots of other features I might have developed in that time.

Check this article containing info on historical debugging feature:
http://channel9.msdn.com/posts/VisualStudio/Historical-Debugger-and-Test-Impact-Analysis-in-Visual-Studio-Team-System-2010/#Page=1

I jumped in joy when reading about this killer feature (which I prayed for 10 yrs ago) until I discovered that regular C++ isn`t suported.

So, I guess I`ll stay with VC6 for another decade, as a family man there`re lots of other things I have to shell out for, instead of just a shiny new interface ...

My gut reaction to the thread title is "yes, having to depend on MS Visual C++ 6.0 is a problem".

Quote:Original post by joe1024
I think you`re all making too much mess about VC6. I still use it at home for all of my home game projects and it works just fine.

For programming in the language you've learned, sure. For programming in C++, it most assuredly does not.

Quote:Yeah, it`s not exactly standard-compliant but does the end user care ? Hardly.

If he wants things to behave the way the language standard guarantees, and have access to the modern standard library, and compile recently written code that assumes everything is as it ought to be, he damn well cares.

Quote:However, you`re wrong about VS2008 being free. It`s not if you need to maintain your MFC dialogs, which you need to pay for in Standard version.

MFC? You're kidding me?

Quote:How is it free if I am to completely redesign/rewrite all UI stuff for my editor? That time can be hardly declared as free, since it`s going to cost me lots of other features I might have developed in that time.

OMG, code doesn't last forever. Imagine that! You might instead take the opportunity to fix issues with the existing code while bringing it in line with modern standards. You might find that the result is much shorter and more expressive, and you might improve your skills.

Quote:Check this article containing info on historical debugging feature:
http://channel9.msdn.com/posts/VisualStudio/Historical-Debugger-and-Test-Impact-Analysis-in-Visual-Studio-Team-System-2010/#Page=1

I jumped in joy when reading about this killer feature (which I prayed for 10 yrs ago) until I discovered that regular C++ isn`t suported.

So because a feature in the planned next release of the software isn't going to work as perfectly as you'd hope, you're going to stick with a several-versions-older release? Seriously, this is analogous to deciding to stick with Windows 98 because you heard bad things about an upcoming service pack for Vista. Just thought I'd throw Windows 98 in there to remind you of what kind of time scales we're talking about here. Ten years is an eternity in computing.

Quote:So, I guess I`ll stay with VC6 for another decade, as a family man there`re lots of other things I have to shell out for, instead of just a shiny new interface ...

Let me ask, with this attitude, why did you bother migrating from C to C++ in the first place? Or from assembly for that matter?

Quote:Original post by Zahlman
For programming in the language you've learned, sure. For programming in C++, it most assuredly does not.

Yeah, the standard was acknowledged after VC6 came out, so there are few glitches here and there (e.g. templates and other smaller issues).

Quote:Original post by Zahlman
If he wants things to behave the way the language standard guarantees, and have access to the modern standard library, and compile recently written code that assumes everything is as it ought to be, he damn well cares.

Oh, sorry - I meant users of the end application. I`m the only user of the engine.

Quote:Original post by Zahlman
MFC? You're kidding me?

No, I still have my interface for my editor coded in MFC/WinAPI. How long would it take to completely exchange all UI-realted stuff from MFC into something more current ? Would there be some advantage, except maybe less maintanance for the new API/method ?

Quote:Original post by Zahlman
OMG, code doesn't last forever. Imagine that! You might instead take the opportunity to fix issues with the existing code while bringing it in line with modern standards. You might find that the result is much shorter and more expressive, and you might improve your skills.

I understand your point. You`re right. Except that it would waste all my previous years of effort. I`d have to rewrite whole engine from scratch if I were to port it to C#. That`s a lot of work and it would cost you maybe a year of your life, plus lots of features that would be done, if you didn`t start the rewrite.

Quote:Original post by Zahlman
So because a feature in the planned next release of the software isn't going to work as perfectly as you'd hope, you're going to stick with a several-versions-older release? Seriously, this is analogous to deciding to stick with Windows 98 because you heard bad things about an upcoming service pack for Vista. Just thought I'd throw Windows 98 in there to remind you of what kind of time scales we're talking about here. Ten years is an eternity in computing.

Well, I`m still waiting for the feature which is worth paying for. And this "Undo debugging" feature looked extremely promising ! However, regular C++ is an ancient language for MS (just like Cobol), so I don`t see a point of buying a SW because of the feature which I can`t use unless I`m programming in a specific langauge. But I can`t port all of my work to C# now. How long will that take and what would be the benefit ? Still, with the current rate of advances, it might well happen that by the time I`m done with porting (actually rewriting), C# will be declared as obsolete, effectively loosing maybe 1 year of my life. MS is known for burning bridges whenever they see it appropriate.
I know that it now seems extremely improbable, but would you guess 10 yrs ago how wil C# spread ? Exactly, you couldn`t at that time, and that`s my point.
So, I might just as well stay with C++/DirectX and loose nothing.

Quote:Original post by Zahlman
Let me ask, with this attitude, why did you bother migrating from C to C++ in the first place? Or from assembly for that matter?

I jumped straight from assembler to Pascal/Delphi, then directly to C++. I had to make the switch, because that was the only viable choice at that time. Plus, it doesn`t hurt to learn new language.


I almost made the switch to C#/XNA, in which case I would have to use the VS2k8. But since MS is so picky as to whose EXE file doesn`t smell rotten, I have to stay back. The longer and more you code in one language/API, the tougher it will be in future to just scrap all your work and start anew.