VS6 --> VS2005
-
VC6 is a terrible C++ implimentation, there are many improvements which could cause problems with your code, depending on how standards complaint it is.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
Hi, I have to port a few (old) applications written in C++ with VS6 and MFC to VS2005 under Vista. Have anybody done that already? Is it just rebuilding everything without any problems? What can I expect? Are there any advantages with VS2005 compared to VS6? Thanks
There is a service pack available, and the comments below concerning COledateTime are no longer completely correct, but there are issues that we encountered that everyone should be aware of. If you use any CRT functions, be prepared to see dozens - if not hundreds or thousands - of warnings regarding deprecated code. The easy fix is to add a compiler definition (_CRT_SECURE_NO_DEPRECATE) to your project settings, and that will address almost all of those. The hard fix is to actually replace all of those deprecated function calls to the secure versions. This will take a lot longer than a simple compiler directive. VS2005 also flags other things that VC6 ignores, such as
constdefinitions that don't have a specified type. VC65 defaulted such items toint, but VS2005 throws up a warning about it. Another bugaboo is handling offorloops. The loop control variable is scoped more tightly (and according to the ANSII standard) so that you are required to re-declare the variable for each for loop. So, this:for (int i = 0; i < 5; i++)
{
// do something
}for (i = 0; i < 5; i++)
{
// do something
}will generate and compile error. You need to do it this way:
for (int i = 0; i < 5; i++)
{
// do something
}for (int i = 0; i < 5; i++)
{
// do something
}or this way:
int i;
for (i = 0; i < 5; i++)
{
// do something
}for (i = 0; i < 5; i++)
{
// do something
}There are MANY changes to MFC. The most damaging involves COleDateTime. It seems MS decided that a m_dt value of 0.0 (12/31/1899) is now COleDateTime::invalid, despite the fact that COleDateTime supports dates all the way back to 12/31/100 (generates a negative value for m_dt). What a pain in the ass. There are also many deprecated functions, and the compiler doesn't like some ported message handling code due to its more strict type compliance. The IDE is NOT friendly to unmanaged C++/MFC programmers. In a word, it SUCKS. In closing, I think the compiler helps you to fix things in your code that would never have been found with VC6. There are now "secure" versions of most of the CRT string-related functions that help to prevent buffer overflows. I think it's a good idea to port to VS2005 because you should always use the latest tools when developing apps. Make double-damn sure you regression test EVERYTHING, *especially* if it involves date handling, and before porting, install the service pack
-
There is a service pack available, and the comments below concerning COledateTime are no longer completely correct, but there are issues that we encountered that everyone should be aware of. If you use any CRT functions, be prepared to see dozens - if not hundreds or thousands - of warnings regarding deprecated code. The easy fix is to add a compiler definition (_CRT_SECURE_NO_DEPRECATE) to your project settings, and that will address almost all of those. The hard fix is to actually replace all of those deprecated function calls to the secure versions. This will take a lot longer than a simple compiler directive. VS2005 also flags other things that VC6 ignores, such as
constdefinitions that don't have a specified type. VC65 defaulted such items toint, but VS2005 throws up a warning about it. Another bugaboo is handling offorloops. The loop control variable is scoped more tightly (and according to the ANSII standard) so that you are required to re-declare the variable for each for loop. So, this:for (int i = 0; i < 5; i++)
{
// do something
}for (i = 0; i < 5; i++)
{
// do something
}will generate and compile error. You need to do it this way:
for (int i = 0; i < 5; i++)
{
// do something
}for (int i = 0; i < 5; i++)
{
// do something
}or this way:
int i;
for (i = 0; i < 5; i++)
{
// do something
}for (i = 0; i < 5; i++)
{
// do something
}There are MANY changes to MFC. The most damaging involves COleDateTime. It seems MS decided that a m_dt value of 0.0 (12/31/1899) is now COleDateTime::invalid, despite the fact that COleDateTime supports dates all the way back to 12/31/100 (generates a negative value for m_dt). What a pain in the ass. There are also many deprecated functions, and the compiler doesn't like some ported message handling code due to its more strict type compliance. The IDE is NOT friendly to unmanaged C++/MFC programmers. In a word, it SUCKS. In closing, I think the compiler helps you to fix things in your code that would never have been found with VC6. There are now "secure" versions of most of the CRT string-related functions that help to prevent buffer overflows. I think it's a good idea to port to VS2005 because you should always use the latest tools when developing apps. Make double-damn sure you regression test EVERYTHING, *especially* if it involves date handling, and before porting, install the service pack
-
Terrible it is. Unfortunately I still have to use it at work :(
Steve
This is Christian's standard response when a discussion of VC6 vs VS2005 is concerned. I'm pretty sure he's bound a macro to a key so he doesn't actually have to type it out every time - he hits one key and it automatically fills in the text for him. (I'm sure he's concerned that he wasn't able to create the macro with VS2005, though.) A good programmer knows about the limitations of his tools and takes precautions against poor coding practices when using said tools. Christian is a good programmer, but he's a little hung up on this VC6 thing. :)
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
There is a service pack available, and the comments below concerning COledateTime are no longer completely correct, but there are issues that we encountered that everyone should be aware of. If you use any CRT functions, be prepared to see dozens - if not hundreds or thousands - of warnings regarding deprecated code. The easy fix is to add a compiler definition (_CRT_SECURE_NO_DEPRECATE) to your project settings, and that will address almost all of those. The hard fix is to actually replace all of those deprecated function calls to the secure versions. This will take a lot longer than a simple compiler directive. VS2005 also flags other things that VC6 ignores, such as
constdefinitions that don't have a specified type. VC65 defaulted such items toint, but VS2005 throws up a warning about it. Another bugaboo is handling offorloops. The loop control variable is scoped more tightly (and according to the ANSII standard) so that you are required to re-declare the variable for each for loop. So, this:for (int i = 0; i < 5; i++)
{
// do something
}for (i = 0; i < 5; i++)
{
// do something
}will generate and compile error. You need to do it this way:
for (int i = 0; i < 5; i++)
{
// do something
}for (int i = 0; i < 5; i++)
{
// do something
}or this way:
int i;
for (i = 0; i < 5; i++)
{
// do something
}for (i = 0; i < 5; i++)
{
// do something
}There are MANY changes to MFC. The most damaging involves COleDateTime. It seems MS decided that a m_dt value of 0.0 (12/31/1899) is now COleDateTime::invalid, despite the fact that COleDateTime supports dates all the way back to 12/31/100 (generates a negative value for m_dt). What a pain in the ass. There are also many deprecated functions, and the compiler doesn't like some ported message handling code due to its more strict type compliance. The IDE is NOT friendly to unmanaged C++/MFC programmers. In a word, it SUCKS. In closing, I think the compiler helps you to fix things in your code that would never have been found with VC6. There are now "secure" versions of most of the CRT string-related functions that help to prevent buffer overflows. I think it's a good idea to port to VS2005 because you should always use the latest tools when developing apps. Make double-damn sure you regression test EVERYTHING, *especially* if it involves date handling, and before porting, install the service pack
John Simmons / outlaw programmer wrote:
There are MANY changes to MFC. The most damaging involves COleDateTime. It seems MS decided that a m_dt value of 0.0 (12/31/1899) is now COleDateTime::invalid, despite the fact that COleDateTime supports dates all the way back to 12/31/100 (generates a negative value for m_dt). What a pain in the ass.
This has been fixed.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
-
John Simmons / outlaw programmer wrote:
There are MANY changes to MFC. The most damaging involves COleDateTime. It seems MS decided that a m_dt value of 0.0 (12/31/1899) is now COleDateTime::invalid, despite the fact that COleDateTime supports dates all the way back to 12/31/100 (generates a negative value for m_dt). What a pain in the ass.
This has been fixed.
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
As noted at the very top of my original post. BTW, directly setting the member variables in COleDateTime can really hose up your code. Unfortunately, the guy that wrote our code didn't realize it, so now we have dates that have a valid m_dt value, but the status is sometimes null, or invalid. This will throw asserts in the COleDateTime class every time you try to use a date that is null or invalid (because instead of setting/getting the value through the accessor functions, he checked the value of m_dt to indicate validity. I'm in the process of evaluating each date reference in a 300,000 line project (and there's a LOT of date references) because of this issue. This is my hell.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
As noted at the very top of my original post. BTW, directly setting the member variables in COleDateTime can really hose up your code. Unfortunately, the guy that wrote our code didn't realize it, so now we have dates that have a valid m_dt value, but the status is sometimes null, or invalid. This will throw asserts in the COleDateTime class every time you try to use a date that is null or invalid (because instead of setting/getting the value through the accessor functions, he checked the value of m_dt to indicate validity. I'm in the process of evaluating each date reference in a 300,000 line project (and there's a LOT of date references) because of this issue. This is my hell.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
John Simmons / outlaw programmer wrote:
This is my hell.
Still there. huh? :)
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
It's an even bigger hell than you might imagine. :/ I'm compiling in a VM under Virtual PC2007 and using sourceoffsite to do check-ins/outs on the desktop, transferring the files into the vm and back out (it won't compile if you use a shared drive). VPN from a DOD network is involved too.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
It's an even bigger hell than you might imagine. :/ I'm compiling in a VM under Virtual PC2007 and using sourceoffsite to do check-ins/outs on the desktop, transferring the files into the vm and back out (it won't compile if you use a shared drive). VPN from a DOD network is involved too.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
:omg:
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
Exactly - I'm gonna update my monster.com profile this weekend.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
