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.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What strategies have you used to improve build times on large projects?
I have some 800 lines of coding done in C++, the cpp file has some 7-8 classes with equal no objects as well, but the program takes good 7 seconds to build. This is my first program in c++, so I want to know if its normal? or its way too much? Also, it would be really great if someone who's expert in c++ could share some insights which would help a beginner as me.
If it helps in any way I am using Visual Studio 2010.
The time to compile C++ probably varies more than with any other language I've ever used.
One thing that can make a significant difference is what headers you're including. Even though your code may only be 800 lines, if a few of those are #includes, the compiler may easily be looking at thousands of lines (just for reference, #include <windows.h>, by itself, generally means the compiler will look at over 10,000 lines).
A few of us in the C++ chat room were recently doing some tests on a particularly nasty piece of code that has a lot of recursive templates. Even though it's only about 30 lines of code, depending on the parameters you set, it's pretty easy to get compiles times of an hour or more -- and with most compilers (including VC++10 and 11/2012) it's pretty easy to outright crash the compiler.
If the code has little or nothing in the way of headers and/or templates (especially things like recursive templates), then 7.5 seconds to compile seems fairly excessive. Just for comparison, I did a quick test compiling a program I had lying around that's close to the same size (926 lines). That took 0.3 seconds. My machine is something like 5 or 6 years old, so its speed isn't even close to cutting edge either. At the same time, I should add that for compiling that small an amount of code, CPU speed probably isn't the main determining factor. I'd expect an SSD to make a lot more difference than a faster CPU.
C++ is a complicated language that requires more time to compile than many other languages. On top of that Visual Studio itself has additional overhead for building Intellisense databases and such. There's also a linking phase to consider after the actual compilation.
When Visual Studio creates a new project, it typically creates a precompiled header that includes a lot of Windows header files. This would add many thousands of lines to your 800-line source.
7 seconds seems a little slow, but not out of line.
I have ported a piece of C++ code, that works out of core, from Linux(Ubuntu) to Windows(Vista) and I realized that it works about 50times slower on VS2008! I removed all the out of core parts and now I just have a piece of code that has nothing to do with the hard disk.
I set compiler parameters to O2 in Project Properties but still get about 10times slower than g++ in linux!
Does anybody have an idea why it is this much slower under VS?
I really appreciate any kind of hint!
Thanks,
Do you use a lot of the standard C++ library? If so, you might want to turn off the "checked iterators" feature that is on by default in Visual C++ (even in Release mode). Put this before including any standard headers:
#define _SECURE_SCL 0
More info here.
No need to guess. Just hit the "pause" button and look at the stack. The chance that you will miss the problem is 1/50. If you're not sure, do it several times.
Suppose a have a fairly complex class I'm working on. Half the methods are done and tested, but I'm still devolping the other half. If I put the finished code in one cpp and the rest in another, will Visual Studio (or any other IDE for that matter) compile faster when I only change code that's in the "work-in-progress" cpp?
Thanks!
Yes, I believe Visual Studio compiles incrementally, so as long as you hit Build and not Rebuild All you should get faster compile times by splitting out.
However, you should really be splitting out because of code-factoring reasons i.e. each class should have a single purpose etc. etc... I'm sure you know.
It really depends. For a very large project, link time can often be considerably more expensive than the time to compile a single file. In our codebase at work (a game based on the Unreal Engine) we actually found that making "bulk.cpp" files that include many other files (effectively fewer translation units) decreases the turn around time significantly.
Even though individual compile time for a small change was increased, overall compile time (full rebuild) and link time (which happens even for a small change) both decreased dramatically.
As long as the header file doesn't change (assuming both .cpp's include the same header) then only the changed .cpp files will be compiled.
This is true for most IDEs at the very least. I haven't had experience in directly invoking compilers like gcc so I can't comment on that.
The answer is probably yes because you'll probably be performing incremental builds (compiling only the .cpp that changes) and pre-compiled headers. If you are not using either of these features, then you'll get slower builds. I'm pretty sure that a default Visual Studio C++ projects uses both incremental builds and pre-compiled headers.
Yes it will be faster.
But more importantly: Don't worry about this, if your class is so large that it's taking a lot of time on a modern processor it's god's way of saying your class needs to get refactored into smaller pieces.
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.