I have an old application written with VC++ 6.0, that I have to maintain. The application is quite large, and it would require a lot of time to convert it to a newer VC++ (like VS2005).
The problem is, that every time I make the smallest changes in the code, the solution (.dsw-file) is destroyed.
I use a VMware Virtual Machine running Windows XP 32bit as Development Environment.
Has anyone else experienced the same problem with Microsoft Visual C++ 6.0?
Hard to give advice, VS6 is not well known to spontaneously destruct project files. You could arbitrarily set the read-only attribute on the .dsw file, you ought to get some kind of message when whatever code is doing this finds out it can no longer delete the file.
I have to add some unwelcome advice. Using a grossly outdated version of Visual Studio is okayish, but as time ticks on the inconveniences and quirks build up. It never gets better. Until you get to a point where investing the time to update the project (don't pick the grossly outdated VS2005) gets to be competitive with the amount of time you waste keeping the old one going. Sounds like D-day has arrived. Time to ditch it.
Related
I am looking for a C++ IDE in which I can actively play the game and test the updates live instead of testing it, redoing th code, compiling it and running it again. I'm running Windows 7 x86 professional.
This isn't really an answer, and so probably shouldn't get upvotes, but has information.
I don't know of any C++ IDE that can do runtime updates of code, but it's definitely not impossible. There's lots of C++ assemblers which already JIT code, live updates is merely the next step that no IDE has taken quite yet that I know of.
asmjit can JIT C++
Visual Studio can JIT C++/CLI (which isn't quite C++) (RMartinho corrects that VIsual Studio compiles C++/CLI to IL, and then JITs the IL. Tehcnically different.)
cling uses the clang fruntend and LLVM backend, which has a JIT code generation system.
R.Martinho has also reminded me that Microsoft Visual Studio already has this feature. http://msdn.microsoft.com/en-us/library/esaeyddf(v=vs.100).aspx If you "stop" the code, you can make changes, and it will apply those changes and resume execution.
There's an interesting project at http://runtimecompiledcplusplus.blogspot.co.uk/ that is working on this problem and looks like it might work for you; I haven't used it myself but it looks active if still a little raw. It uses the Visual Studio 2010 compiler.
You can't run C++ code without compiling. Minor syntactic differences between languages shouldn't be an issue so you shouldn't limit yourself to just one language.
I suggest you give Unity a chance; there's a fairly robust free version available. You can write scripts in C# (a language similar to C++), or UnityScript (somehting similar to JavaScript) or Boo (similar to Python) and you can test the results right away, without having to compile.
What about Edit and Continue in Visual Studio? In order to use it, you have to pause execution (either by breakpoint or Pause button), recompile and resume. Note, that you can edit the code while the program is running. I know you can't test the game live, but you don't have to reload resources etc. It's IDE integration makes it really easy and straightforward to use.
If you want changes to be visible live, though, consider using script language such as Lua. One of their purposes is what you want to achieve.
I've listed the options for runtime compilation of C++ code on the alternatives wiki page of Runtime Compiled C++.
From the sounds you may interested in either Recode or Alcanterea.
Organize your C++ game to use plugins, and add a feature to load a new (binary version of) plugin during the game.
Then, you could play your game, recompile a plugin, reload it (so invoke your dynamic linker at runtime), and continue playing.
It is not failproof, but it might usually work.
Of course you cannot unload a plugin which has some active call frame on the (or some thread's) call stack. I would suggest to avoid unloading old plugins...
The project I work on has recently been switched from a horribly antiquated revision control system to Subversion. I felt like I had a fairly good understanding of Subversion a few years ago, but once I learned about Mercurial, I forgot about Subversion quickly.
My question is targeted at those who work with a sizable number (15+) developers on the same branch in Subversion.
Let's say you checkout rev N of the repository. You make some changes and then commit. Meanwhile, other developers have made changes to other files. You hear about another developers changes to subsystem X and decide you need them immediately. You don't want to update the entire working copy because it would pull in all sorts of stuff and then you would have to do a lengthy compile (C++ project). The risk I see is that the developer updates only subsystem X not realizing that the new code depends on a recent change in subsystem Y. The code compiles, but crashes at runtime.
How do you deal with this?
Does the developer report what they think might be a bug (even though it's not a bug)?
Do you require developers to update their entire working copy before reporting a bug? Wouldn't this deter bug reports?
Do you prevent this situation from occurring through some mechanism I haven't thought of?
Since you committed all your work in progress, you have no reason not to update your copy with the entire latest revision. The lengthy compile is part of the price of a large project. The compile time is almost always less than the time spent trying to determine whether you have a bug, or whether there's some obscure incompatibility because you didn't check everything out.
That project had distributed compiles to all the workstations in the group. Since we had about 15 computers for the task, that meant what would normally be a 6 hour or so build took about 25 minutes.
The responsibility to keep track of dependencies is the develloper who introduce it.
In this case develloper X should make sure the change work with current version of other subsystems. Or at least document which versions it works with.
The ways I have seen helping devellopers deal with this are.
Include dependency checking in the build system. Many open source project does this in a .configure script.
Configure the version control system to handle this for you. I don't know to do this in subversion.
This is obviously not a cure for long compile times but it helps to avoid unnecesary rebuilds.
Complex dependeny graphs is also an indication of questionable design. It may be good idea to refactor the code to reduce coupling between subsystems.
One of our old C++ projects is still with Visual Studio 6. Once a year I try to convert it in to a higher Visual Studio Version but it's not easy because not all the code is written by us.
Anyway, I finally succeeded in converting the project to VS2005 after fixing a few hundred lines of code. But compiling the projects takes a very long time! Much longer than in VS6.
Some classes have a lot of codelines, a few thousands even. These are just arrays to be filled in the code with a lot of items. I know it's not the perfect solution but this is how it is at the moment and VS6 never had a problem with that.
Maybe there are just some settings I have to adjust to speed things up but if it stays like it is now I will keep it as an VS6 project since I don't want to sit at my desk all day doing nothing.
Any ideas?
Differences in compile times are normal. The C++ compiler from VS2005 is significantly more compliant to standard C++ than VC6 was. There is a huge difference between these two compilers.
VS2005 produces more optimized code and thus has to spend extra time figuring out how to make it faster.
See if you can find the smallest modules that compile quickly, and very slowly in VS05, and see what they don't have in common. Add in the elements from the slow module to the fast one until you get a sudden slowdown. That is the cause of the problem.
Sounds like you are a few years behind in your "once-a-year-upgrade", no?
Check to make sure you didn't turn off pre-compiled headers.
Get Incredibuild.
Definitely worth the money you pay for it.
What it does is delegate compilation of files to idle build "agents" on the network, get the results back and link it on the build co-ordinator. The more machines the better. I was impressed with the reduction of build time.
Of late I'm facing the issues that points finger to VC6 compiler.
Few of them are:
A function-try-block doesn't work. Related Q
in-class constant doesn't work.
__FUNCTION_ (Macro to get function name) doesn't work
The latest addition is it doesn't allow void functions to be passed as part of for_each.
The below example is not compiling with VC6 compiler. It says "error C2562: '()' : 'void' function returning a value". It looks like VC6 doesn't like void functions to be passed to for_each.
class Temp
{
public:
Temp(int i):m_ii(i)
{}
int getI() const
{
return m_ii;
}
void printWithVoid()
{
cout<< "i = "<<m_ii<<endl;
}
bool printWithBool()
{
cout<< "i = "<<m_ii<<endl;
return true;
}
private:
int m_ii;
};
int main(void)
{
std::vector<Temp> arrTempObjects;
arrTempObjects.push_back(Temp(0));
arrTempObjects.push_back(Temp(2));
//Doesnot work, compiler error
std::for_each(arrTempObjects.begin(), arrTempObjects.end(), std::mem_fun_ref(&Temp::printWithVoid));
//Works
std::for_each(arrTempObjects.begin(), arrTempObjects.end(), std::mem_fun_ref(&Temp::printWithBool));
return 0;
}
Have you faced any other issues related to VC6.0. Any workaround to resolve these issues ? Or is it time to change the compiler?
Quite frankly I can hardly understand why you wouldn't buy a modern computer and switch to Visual Studio 2008.
VC6 has got a deficient STL, poor C++ standard compliance and obsolete GUI.
You shouldn't let your competitors use better tools than you.
Well, here's the thing. The VC6 compiler sucks. However... the IDE is pretty good.
VS2005 has much better source control support. Otherwise, it's much slower debugging, has a crappy output pane that exponentially decays on inserting output lines (what absolute garbage coding is that?), the help system is many times slower, and debug and continue (possibly Microsoft's best feature over other IDEs) is considerably more broken.
.NET? Sure, VS20xx is the only way to go. However, for one small client that is sticking with VC6/MFC (for interfaces to embedded systems, etc) I actually enjoy working with VC6. It's just FAST.
2008? I'd like to... but it takes a while for my clients to migrate. Nobody has, yet.
Is it time to say goodbye to VC6
compiler ?
Yes.
VC6 cannot do much of any kind of modern C++. I recall I tried to use one of the boost libraries ages ago like probably Graph and it was giving "INTERNAL COMPILER ERROR" all over the place so eventually I chucked that in.
The no-brainer answer is yes, and ASAP. You have free alternatives like VC++ express and Code::Blocks, if the cost as in issue. The pain in solving compatibility issues is IMO no reason not to upgrade because you will have to do it some day anyway and it only gets harder.
The only reason I see for a possible obstacle is if you have MFC code that will be difficult/time consuming to port. In that case you can't use VC++ express (no support for MFC) and you have to make the investment for at least the VS std. edition. That will cost you about EUR 300 (depending on where you live).
I changed from VC++ 6.0 to Code::Blocks (which is FOSS) with g++ a few months ago and haven't really looked back. I miss the VC++ debugger a bit, as the gdb implementation in CB is nowhere near as slick, but that's about all. Some things in the IDE work better (code completion, tooltips, dependancy xalculation) and the compiler is obviously much better.
Regarding your points, function try blocks are hardly a widely used feature, and most people think they are pretty useless. And the __FUNCTION__ macro is not part of the C++ Standard, so you shouldn't depend on it too much if portability is an issue.
No, it was time to say goodbye to it a decade ago. Here are a few reasons why:
There are free, standards-compliant compilers available, both from Microsoft and others
VC6 was written before the C++ language was standardized, and it is nowhere near standards compliant. Especially templates and the standard library live in a world of their own, with no tie to how these features actually work in ISO C++. The language it compiles is not C++. It is a hybrid of pre-standard C++, Microsoft extensions, compiler limitations and bugs. Neither of which are desirable.
VC6 is known to generate invalid code in some cases. Not only does it compile a home-made, buggy and nonstandard language, it also makes invalid optimizations causing crashes, or in some cases actually produces bad assembly that simply can not be executed.
It is broken, and it was always broken. It was designed to compile a language that ceased existing about the same time as the compiler was relased (when the language was standardized), and it failed even at that task, with countless bugs, some of which have been fixed in the half-dozen service packs that were released. But not all of them, and not even all the critical ones.
Of course, the downside to this is that your application is most likely just as broken. (not because you're bad programmers, but because it targets a broken compiler. It has to be broken to be accepted by VC6)
Porting that to a standards-compliant compiler is likely to be a lot of work. Don't assume that you can just import your old projects, click "build", and it'll work.
So if you're part of a big business that can't just take a month off to switch compilers, you might have to port it as a side project, while part of the team is maintaining the VC6 version. Don't scrap VC6 until you've successfully ported everything, and it works.
Unless you have a large program to maintain, yes. Switch today!
The Express versions of VC++ are a free download from Microsoft.
I guess this is why so many applications on Windows sucks because people still use VC6. Why mess with broke, never maintained MFC or even Win32 when their is wxWidgets and Qt4 out there way better than MFC could ever be and you you can even use the free additions of Visual Studio 2005+
You can learn to live with VC6s foibles. It almost has a certain retro charm these days. We've been repeatedly providing "just one last VC6 release" of some libraries to a customer for years now. Hard to argue with a customer prepared to pay for the extra work backporting and maintaining a branch. But at some point the cost for us to backport newer features developed in newer VCs will exceed the cost of them upgrading at their end (especially as more boost and Intel TBB creeps into the codebase's head). Or at least I hope that's what'll happen! Worst case it'll happen just as flaky C++0x support appears and we'll be stuck supporting that for them for 10 years...
General rule seems to be that a new version is an upgrade and is thus worthwhile.
However! you have to pick the right time for it, there are so many bugs fixed, but you then need to be aware of the new bugs and variations from the standard.
Set aside time for the upgrade.
Upgrading compiler versions could well be a project in its own right, make sure you have stable code and good tests before you do an upgrade and when you finish prove that it is still working the same.
You may be forced to upgrade when you start to develop for Vista as VC6 doesn't provide for code signing easily and the redist is not in a form that Vista likes. (want at least VC2K5)
Are you updating the OS any time soon? When I researched moving our apps to Vista, I found that Vista doesn't officially support anything before VS 2005 (except for VB 6), and has a page-long list of possible little problems with VS 2005 that may or may not bite you. I recommended delaying until VS 2008 SP1 was available (i.e., when VS 2008 was really usable), and doing the compiler changeover first.
If the project is a special one for a few customers who run it soley on old NT machines, you may want to keep it at VS 6. If you are selling it for any sort of general consumption, you will need to make it Vista-compatible at some point (or 7-compatible, or whatever), and you will need to upgrade.
Using Microsoft Visual Studio 98, Microsoft Visual C++ 6.0 SP6
When running under the debugger, there's only one problem. If I pause the program and resume, everything's fine.
The problem? When I hit a breakpoint, my program stops. But not in a good way; execution halts, I'm thrown out of debug mode into edit mode. All's fine until a breakpoint is hit. And I know it's hitting the breakpoint - I see a flash of the little yellow arrow pointing at the right line of code, local variables in the inspect window and the call stack in that window. And then I'm staring at the editor.
This happens in all projects.
I've uninstalled and re-installed MSVC6. It didn't help.
I'm about to start over on a new PC; before I go that far, anyone know what I've done to this one?
Note: MSVC6 is not my choice, but there are reasons. It's the tool I work with. And, we get to target NT4, so given 2008 can't target NT4 and 2005 has issues with MFC and NT4, MSVC6 it is.
Stop beating on VC6. It's old. The STL was updated in 1996 from HP code written in 1994. C++ was ratified in 1998.
What is the code doing when you are breaking? Can you reduce the situation into a simple test. When I try that I usually find the cause. If you can do that so it still happens then I'll take a look at it for you. I too am unfortunate enough to use VC6 for my day to day work.
Visual C++ Express 2008 can't be used in certain situations.
The first thing I would check is if this project does the same thing on other machines. If not, it could be your box is heading south. If not it's the VC6 project itself.
Typically I get goofiness with the debugger when my program is doing something with the hardware, especially the video.
I would recommend turning off parts of your program until you figure out what part is causing this. If your program is small and not doing much it might be that the project is corrupted and needs to get rebuilt. Make a new project from scratch and put your files and settings back in by hand.
Is it specific to the app you're working on or do all breakpoints in any app break the debugger?
Is anything different if you attach the debugger manually after launching the app normally?
Is the device running out of memory and therefore gives up the ghost when it requires the additional memory to stop at the breakpoint?
Is the device running out of memory and therefore gives up the ghost when it requires the additional memory to stop at the breakpoint?
No, there's over a gig of RAM to go, and even more of virtual memory.
I haven't used MSVC6 in years, but I remember the debugger basically being a flaky piece of crap. Things like this would regularly happen for no apparent reason because it just didn't like your code that day.
In addition to the debugger being a flaky piece of crap, the rest of it was too.
It's STL implementation isn't threadsafe, it doesn't support very much of the C++ standard, and the IDE is sorely lacking in niceties.
I'm pretty sure you also just simply can't use any versions of the Platform SDK from the last 5 years because it's too old to grok them. Not a good thing.
You'd be mad to keep using it when there is Visual C++ Express 2008 which you can download for free.