Moving projects to the newer version of VC++
in [Visual C]
|
Prev: auto_ptr in loop
Next: assign none to COM thread model
From: John_Doe on 10 Apr 2008 15:53 I have inherited a lot of projects using VC++ 6, 2002, 2003 and 2005, most of them MFC based (hence cross-posting in 2 newsgroups). I intend to move all of them to 2008 over the time. I already moved some and did have to make some code changes, mostly due to the fact that newer compiler is more strict in conformance to C++ standard. The applications are producing the same result as far as I can see but I haven't performed any extensive testing. What concerns me is that changes in compiler and/or libraries can produce different executable with different behavior, and that difference may not be immediately obvious, however it will break our applications. Can those of you who had to move a lot of projects from one version of VC++ to another share your experiences? How much of a problem it has been? Is there some documentation on MS website related to this issue?
From: Victor Bazarov on 10 Apr 2008 16:07 John_Doe(a)inbox.ru wrote: > I have inherited a lot of projects using VC++ 6, 2002, 2003 and 2005, > most of them MFC based (hence cross-posting in 2 newsgroups). I intend > to move all of them to 2008 over the time. I already moved some and > did have to make some code changes, mostly due to the fact that newer > compiler is more strict in conformance to C++ standard. The > applications are producing the same result as far as I can see but I > haven't performed any extensive testing. > > What concerns me is that changes in compiler and/or libraries can > produce different executable with different behavior, and that > difference may not be immediately obvious, however it will break our > applications. > > Can those of you who had to move a lot of projects from one version of > VC++ to another share your experiences? How much of a problem it has > been? Is there some documentation on MS website related to this issue? If they compile, it's already better. We had some that had compilation errors, so we dealt with those first. Then, of course, if you have QA, you need to work with them closely to develop some kind of automation in testing, otherwise pushing all the buttons manually is just hard. If you don't have QA, how big is the "lot of projects", really? Most of difficulties we've encountered was due to some miniscule changes the compiler developers made over the years. First and foremost was in VC6 when you could declare the loop counter in one loop, insid the 'for' statement, and then use it afterwards. It changed in 2002, IIRC. Then you have some template rules that were tweaked, but it is possible that you don't have any of that... Managed stuff has changed a bit (they straighten it out, last I heard)... Generally, however, our approach was to deal with one error at a time. I am not aware of any MS documentation that describes potential problems in migrating from version to version. Your application is going to be smaller and faster, and that's good news. V -- Please remove capital 'A's when replying by e-mail I do not respond to top-posted replies, please don't ask
From: BobF on 10 Apr 2008 16:14 <John_Doe(a)inbox.ru> wrote in message news:92d9e010-aa57-48eb-a348-b7a56c87cbca(a)z38g2000hsc.googlegroups.com... >I have inherited a lot of projects using VC++ 6, 2002, 2003 and 2005, > most of them MFC based (hence cross-posting in 2 newsgroups). I intend > to move all of them to 2008 over the time. I already moved some and > did have to make some code changes, mostly due to the fact that newer > compiler is more strict in conformance to C++ standard. The > applications are producing the same result as far as I can see but I > haven't performed any extensive testing. > > What concerns me is that changes in compiler and/or libraries can > produce different executable with different behavior, and that > difference may not be immediately obvious, however it will break our > applications. > > Can those of you who had to move a lot of projects from one version of > VC++ to another share your experiences? How much of a problem it has > been? Is there some documentation on MS website related to this issue? Try searching MSDN for "breaking changes". There are docs that detail these changes for each version.
From: John_Doe on 10 Apr 2008 16:44 On Apr 10, 4:07 pm, "Victor Bazarov" <v.Abaza...(a)comAcast.net> wrote: > John_...(a)inbox.ru wrote: > > I have inherited a lot of projects using VC++ 6, 2002, 2003 and 2005, > > most of them MFC based (hence cross-posting in 2 newsgroups). I intend > > to move all of them to 2008 over the time. I already moved some and > > did have to make some code changes, mostly due to the fact that newer > > compiler is more strict in conformance to C++ standard. The > > applications are producing the same result as far as I can see but I > > haven't performed any extensive testing. > > > What concerns me is that changes in compiler and/or libraries can > > produce different executable with different behavior, and that > > difference may not be immediately obvious, however it will break our > > applications. > > > Can those of you who had to move a lot of projects from one version of > > VC++ to another share your experiences? How much of a problem it has > > been? Is there some documentation on MS website related to this issue? > > If they compile, it's already better. We had some that had compilation > errors, so we dealt with those first. Then, of course, if you have QA, > you need to work with them closely to develop some kind of automation > in testing, otherwise pushing all the buttons manually is just hard. > If you don't have QA, how big is the "lot of projects", really? No, we don't have QA. Projects themselves are not really large but there are about 20 of them > > Most of difficulties we've encountered was due to some miniscule changes > the compiler developers made over the years. First and foremost was in > VC6 when you could declare the loop counter in one loop, insid the 'for' > statement, and then use it afterwards. It changed in 2002, IIRC. Funny thing is that I fixed this loop counter issue in several places while moving one of the projects. I didn't even know you could use it like that, it just "feels wrong". > Then > you have some template rules that were tweaked, but it is possible that > you don't have any of that... Managed stuff has changed a bit (they > straighten it out, last I heard)... There seem to be no templates and managed stuff. > Generally, however, our approach was to deal with one error at a time. > I am not aware of any MS documentation that describes potential problems > in migrating from version to version. > > Your application is going to be smaller and faster, and that's good > news. > > V > -- > Please remove capital 'A's when replying by e-mail > I do not respond to top-posted replies, please don't ask
From: John_Doe on 10 Apr 2008 16:54
On Apr 10, 4:14 pm, "BobF" <rNfOrSePeA...(a)charter.net> wrote: > <John_...(a)inbox.ru> wrote in message > > news:92d9e010-aa57-48eb-a348-b7a56c87cbca(a)z38g2000hsc.googlegroups.com... > > > > >I have inherited a lot of projects using VC++ 6, 2002, 2003 and 2005, > > most of them MFC based (hence cross-posting in 2 newsgroups). I intend > > to move all of them to 2008 over the time. I already moved some and > > did have to make some code changes, mostly due to the fact that newer > > compiler is more strict in conformance to C++ standard. The > > applications are producing the same result as far as I can see but I > > haven't performed any extensive testing. > > > What concerns me is that changes in compiler and/or libraries can > > produce different executable with different behavior, and that > > difference may not be immediately obvious, however it will break our > > applications. > > > Can those of you who had to move a lot of projects from one version of > > VC++ to another share your experiences? How much of a problem it has > > been? Is there some documentation on MS website related to this issue? > > Try searching MSDN for "breaking changes". There are docs that detail these > changes for each version. BobF, your suggestion is right on target - I found just what was looking for. |