有{間}客栈

版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://imcc.blogbus.com/logs/1897725.html

Migrating from MSVC 6.0 to Studio 2005?
Posted by Cliff on Tue Sep 27, '05 02:42 PM
from the pitfalls-from-the-commons dept.
   greywar asks: "While the preferred method would be simply use Linux, unfortunately my company is using Microsoft Visual Studio 6.0 with C++. I have been asked to recomend if we should upgrade to the new upcoming visual studio 2005. Has anyone got any real life experience with moving a project of about 220,000 lines of code, 60,000 lines of comments from the old MSVC to the new Studio 2005 which is currently in Beta? What benefits are there, and what things do we lose? What problems will occur?"

This discussion has been archived. No new comments can be posted.
Migrating from MSVC 6.0 to Studio 2005? | Log in/Create an Account | Top | 130 comments | Search Discussion
Display Options Threshold:  -1: 130 comments 0: 127 comments 1: 108 comments 2: 78 comments 3: 32 comments 4: 13 comments 5: 8 comments Flat Nested No Comments Threaded Oldest First Newest First Highest Scores First Oldest First (Ignore Threads) Newest First (Ignore Threads)  
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
what? concerns about MS compatibility?(Score:4, Funny)
by yagu (721525) * <yayagu@gmail.cLISPom minus language> on Tuesday September 27, @02:43PM (#13660902)
(Last Journal: Friday December 02, @07:57AM)

I'm pretty sure your 60,000 lines of comments will port to the new environment okay. (But I actually have an example of where they didn't.)

real life experience?(Score:2, Funny)
by Yogurt Earl (686692) on Tuesday September 27, @02:46PM (#13660924)
real life experience?

Nope, only work related experience.
Sorry I couldn't help.
.Net 2(Score:3, Informative)
by Fr05t (69968) on Tuesday September 27, @02:48PM (#13660949)
Not sure if this is an issue still (from what I read it didn't seem like MS was going to change it), or even for you.

Several months ago the beta wasn't able to compile .NET 1.0/1.1 - 2.0 only.

Re:.Net 2 by Surye (Score:3) Tuesday September 27, @06:49PM
Re:.Net 2 by Fr05t (Score:2) Wednesday September 28, @08:11AM
Re:.Net 2 by BigJimSlade (Score:2) Wednesday September 28, @09:55AM
Comments are for wimps.(Score:2, Funny)
by Anonymous Coward on Tuesday September 27, @02:53PM (#13660995)

grep -v -e "^\/\/" oldfoo.c > newfoo.c
1 reply beneath your current threshold.
Very poor(Score:5, Informative)
by feebdaed (146792) on Tuesday September 27, @02:55PM (#13661011)
My last experence with VS 2005 was very poor. The IDE itself may be ok, but the real problem lies with the C++ compiler.

On a project roughly the same size as yours. Moving from VS 2003 to VS 2005 generated 400+ compiler errors and thousands of warnings. This is up from 0 errors and 0 warnings with VS 2003 and g++.

The problem is one of lockin. MS depricated ALL of the C standard library. Every strlen() is now a compile error. Best of all the only documented way to enable the old functionality (some obscure #pragma) was broken.
Re:Very poor by Keith Russell (Score:3) Tuesday September 27, @03:26PM
Re:Very poor(Score:5, Informative)
by bushidocoder (550265) on Tuesday September 27, @03:36PM (#13661464)
(http://slashdot.org/)
Functions like strlen have been depricated - in fact, Microsoft depricated most of the standard C library in favor of what they call the "Safe C libraries" which simply replace strlen with range limitted functions like strnlen. Its a pain in the butt to move, but honestly, its a good idea.
Using the old functions generates a compiler warning that you are linking against the old unsafe libraries. It should only generate an error if you have signalled the compiler to treat warnings as errors. You can suppress the warnings and ignore them, or leave them in place and slowly migrate your code to the safer runtime library. That said, there are a few compiler errors (especially related to scope of variables on the stack) you can get now as they tightened up their standards a bit.

[ Parent ]
Re:Very poor by ckelly5 (Score:3) Tuesday September 27, @04:14PM
Why is strlen "unsafe"? by mangu (Score:2) Tuesday September 27, @05:54PM
Re:Why is strlen "unsafe"? by cookd (Score:3) Tuesday September 27, @10:11PM
Re:Why is strlen "unsafe"? by Anonymous Brave Guy (Score:2) Wednesday September 28, @12:10PM
Re:Very poor by jmccay (Score:3) Tuesday September 27, @06:16PM
Re:Very poor by bushidocoder (Score:2) Wednesday September 28, @01:55PM
1 reply beneath your current threshold.
Re:Very poor by jgrahn (Score:1) Wednesday September 28, @03:16PM
Re:Very poor by frank2 (Score:1) Tuesday September 27, @03:27PM
Re:Very poor by Hard_Code (Score:2) Tuesday September 27, @03:30PM
Re:Very poor by thsths (Score:2) Tuesday September 27, @03:46PM
Re:Very poor by Anonymous Coward (Score:2) Tuesday September 27, @05:31PM
Re:Very poor by cookd (Score:1) Tuesday September 27, @10:04PM
Re:Very poor by Kawahee (Score:1) Wednesday September 28, @03:20AM
Re:Very poor by Kawahee (Score:1) Wednesday September 28, @06:53AM
1 reply beneath your current threshold.
Re:Very poor by RupW (Score:2) Wednesday September 28, @11:12AM
Re:Very poor by Anonymous Brave Guy (Score:2) Wednesday September 28, @12:21PM
Should you upgrade?(Score:1)
by Threni (635302) on Tuesday September 27, @02:56PM (#13661016)
Don't you have to upgrade to Visual Studio .NET to use the more recent DirectX SDKs? Is your case any different?
Painful(Score:2, Informative)
by 0kComputer (872064) on Tuesday September 27, @02:58PM (#13661044)
if 6.0 to 2003 is any indication Get ready for a lot of manual header adding. To convert, I had to create fresh ATL projects and re add all my header files because VS 2005 doesn't recognize the dsw. Kind of a pain in the ass, and, I cant really think of any benifits attained from doing it. If you're just coding w/ C/C++ id stick to 6.0. If you are trying to migrate to .net/c#, well I guess you'll have to go through this sooner or later.
Re:Painful by Profound (Score:2) Tuesday September 27, @07:56PM
Re:Painful by UnknownSoldier (Score:2) Wednesday September 28, @01:40PM
Re:Painful by UnknownSoldier (Score:1) Wednesday September 28, @04:27PM
1 reply beneath your current threshold.
One Tip...(Score:5, Funny)
by GypC (7592) on Tuesday September 27, @03:00PM (#13661061)
(http://slashdot.org/ | Last Journal: Tuesday September 27, @08:37AM)
... before moving your production code to any environment that is still in beta, you must destroy all of your backups.
Experience with .NET(Score:4, Informative)
by Anonymous Coward on Tuesday September 27, @03:01PM (#13661066)
Our code base is about 1M lines of C++ code + comments. We support production builds on MSVC6 and Linux (gcc 3.2) and solaris. We recently started building in .NET 2003. Apart from issues that we already confronted when porting to Linux (we had previously has some code using old iostreams, no longer supported after VC6), we had no siginificant porting issues. One issue that we have not yet solved is that link times are much worse, particularly when building against debug libraries. This is the main thing keeping us from moving to .NET for our production builds. We are hoping the situation improves with 2005, and if so may leap frog over 2003.
Re:Experience with .NET by KMAPSRULE (Score:1) Tuesday September 27, @03:27PM
Re:Experience with .NET by cookd (Score:1) Tuesday September 27, @10:17PM
Some unfixed bugs still ...(Score:5, Funny)
by twoflower (24166) on Tuesday September 27, @03:07PM (#13661120)
What problems will occur?
Make sure you read KB3090309, "KNOWN ISSUE: Earth crashes into Sun" before upgrading.
Re:Some unfixed bugs still ... by OldManAndTheC++ (Score:2) Tuesday September 27, @11:35PM
1 reply beneath your current threshold.
You should be fine..(Score:4, Informative)
by parryFromIndia (687708) on Tuesday September 27, @03:07PM (#13661124)
In my experience MS cares a lot about backwards compatibility. So if you used standard C++ code (may be with some anti-standards tweaks to get the VC++ 6.0 compiler work - it's a shitty compiler when it comes to C++ standards compliance) you should be fine. The APIs are still there, albeit some are now deprecated like the unsafe string handling functions - Your code will still compile but with warnings.
Needless to say your projects will be converted automatically.
And you might want to clean up the code of any VC6 compiler specific kludges as the VS 2005 C++ compiler is nearly perfect when it comes to C++ standards compliance.
If you are using any 3rd party libraries compiled with VC++ 6.0 you might need to get an updated version compiled for VS2005. I found it problematic mixing C++ libraries compiled by VC6 and VC7, for example.
Re:You should be fine.. by abradsn (Score:1) Tuesday September 27, @06:26PM
Sloppy Programming will cause issues(Score:3, Informative)
by KMAPSRULE (639889) <ccalandra@gmai l . com> on Tuesday September 27, @03:07PM (#13661131)
(http://www.calandranet.com/ | Last Journal: Sunday November 13, @09:48AM)
We Did a test run of a project roughly Twice your Stated Size from VS2003.NET to 2005.NET and The main issues that cought us were the Company we inherited the project from had very poor Programming practices (Going From VC6 to 2003.Net was a nightmare due to their sloppiness)

so things like this (which you shouldnt be doing anyway):
{

for (int i=0; i< someLimit; i++)
{
doSomething(i);

}

for (i=0; i< someLimit2; i++)
{
doSomething2(i);

}
}
Wont Work Anymore
Several deprecation issues but overall it was a fairly smooth transition, but for us we already suffered and bled going from VC6 to 2003.NET
Re:Sloppy Programming will cause issues by frank2 (Score:1) Tuesday September 27, @03:22PM
Re:Sloppy Programming will cause issues by KMAPSRULE (Score:1) Tuesday September 27, @03:33PM
Re:Sloppy Programming will cause issues by Rufus88 (Score:2) Tuesday September 27, @06:23PM
Re:Sloppy Programming will cause issues by ConceptJunkie (Score:3) Tuesday September 27, @04:52PM
Re:Sloppy Programming will cause issues by Rufus88 (Score:3) Tuesday September 27, @06:16PM
Re:Sloppy Programming will cause issues by ConceptJunkie (Score:2) Tuesday September 27, @06:56PM
Re:Sloppy Programming will cause issues by Henry V .009 (Score:3) Tuesday September 27, @08:29PM
Re:Sloppy Programming will cause issues by Haeleth (Score:1) Wednesday September 28, @11:29AM
Re:Sloppy Programming will cause issues by Henry V .009 (Score:2) Wednesday September 28, @11:44AM
Re:Sloppy Programming will cause issues by ConceptJunkie (Score:2) Thursday September 29, @04:41PM
Re:Sloppy Programming will cause issues by Kosgrove (Score:1) Wednesday September 28, @10:20AM
Re:Sloppy Programming will cause issues by cookd (Score:1) Tuesday September 27, @11:11PM
Re:Sloppy Programming will cause issues by ConceptJunkie (Score:2) Wednesday September 28, @08:58AM
Re:Sloppy Programming will cause issues by RupW (Score:2) Wednesday September 28, @11:21AM
Re:Sloppy Programming will cause issues by Anonymous Brave Guy (Score:2) Wednesday September 28, @12:27PM
Re:What is the "proper" scope? by boneshintai (Score:2) Tuesday September 27, @05:01PM
Re:What is the "proper" scope? by turator (Score:1) Thursday September 29, @12:56AM
1 reply beneath your current threshold.
1 reply beneath your current threshold.
Migration Problems(Score:3, Insightful)
by megaversal (229407) on Tuesday September 27, @03:11PM (#13661163)
I've had lots of various problems with small projects. What I've learned to do is port a few things at a time, especially if you have a lot of libraries and other things, you can try porting over a library and fix that up to keep running with other VS6.0 stuff while you slowly move it all over.

Of course the fun one would be download the trial beta and take a copy of all the code, build it, and see how many errors you get (hint: it will probably be a lot).
Go for it(Score:5, Informative)
by frank2 (63179) on Tuesday September 27, @03:12PM (#13661172)
Our company's main product currently has around 1.9 million lines of code. I've been running the beta compiler for months, and have found excellent performance gains over our normal builds which are created with VC6. Generally, I'm seeing execution times of around 2/3 of what they were before. This is on P4's, Athlons, and AMD-64's.

      I had no trouble converting my projects from VC7 to the Beta, and I presume the VC6 to Beta would work well too. There will be a ton of warnings at first about deprecated functions like strcpy, but you can easily tell the compiler to ignore those (or use the new M$ functions if that's your style).

      There are tons of new features that I haven't had a chance to use yet, but am looking forward to trying (like OpenMP).

      And yes, this endorsement even comes from someone who in general is VERY anti-M$.

1 reply beneath your current threshold.
VC++ 2005 issues for embedded developers(Score:3, Informative)
by demigod2k (471203) on Tuesday September 27, @03:24PM (#13661302)
I would love to use VS2005 as an IDE for embedded development. Unfortunately, certain things are easy with VC6 and nmake, but awkward or impossible with VS2005 and VCBuild.

I was unable to setup my cross-compiler. With VS2005 it's possible to override the rule for *.c files and specify an alternate compiler, but there is no way (in beta2) to replace the built-in rule for *.o files and use an alternate linker. VC++ "custom build rules" are insufficient because they only act upon files that appear in the project, not files that are generated as output from a previous build stage. There are some half-baked workarounds like adding "dummy" *.o files to the project, but nothing I've found reasonable.

The MSBuild system looks awesome, but VC++ 2005 only has support for the VCBuild subset. It's a lot more limiting, and something to keep in mind.
Re:VC++ 2005 issues for embedded developers by Anonymous Brave Guy (Score:2) Tuesday October 04, @07:36AM
If it ain't broke...(Score:3, Insightful)
by N7DR (536428) on Tuesday September 27, @03:30PM (#13661379)
I have a project that's about 1/3 the size of yours, with VC++ 6.0 as the development environment.

Out of interest I purchased VC++.NET 2003 a while ago.

Once I fired it up and tinkered a bit with the IDE, all thought of porting the project went away. Things look quite different (and, at least in my case, the help that came in the package was a big fat zero). I eventually worked out how to build a small test project and have it run. But to take a complex pre-existing project looked like a job that one would take on only if one absolutely needed something that was only available in 2003 .NET. (In fact, my first reaction on seeing the IDE was: Good Grief! Why does everything nowadays have to be so complicated? I had hoped for a reaction along the lines of: Oh good! This looks like something I'm used to. But it was Not To Be.)

Now, rumour has it that the 2005 .NET compiler is going to have lots of support for fancy stuff like template metaprogramming. So I can see using it for new projects if the new stuff is going to be useful in those projects. But as for porting an old project, I have to assume that 2005 is going to be at least as far removed from 6.0 as 2003 .NET was. And since you already have the project building and working under 6.0, I would not recommend the switch.

Maybe if you have the capability and version control resources to keep using 6.0 as your mainline code while you tinker to get 2005 .NET working, then that might be reasonable. But unless you have spare people/time, I honestly don't think it would be wise to try to make the switch

1 reply beneath your current threshold.
Why bother?(Score:4, Insightful)
by DavidYaw (447706) on Tuesday September 27, @03:31PM (#13661398)
(http://slashdot.org/)
The question to ask is, why upgrade at all? Is there something wrong with MSVC 6? Does it all of the sudden not work?

If the only reason to upgrade is because some not-too-informed person (be it PHB or novice programmer) wants to be running the latest-and-greatest, then don't.
Re:Why bother? by frank2 (Score:2) Tuesday September 27, @03:49PM
Re:Why bother? by PseudoQuant (Score:1) Tuesday September 27, @04:03PM
Re:Why bother?(Score:5, Interesting)
by slcdb (317433) on Tuesday September 27, @04:02PM (#13661740)
(http://www.danm.net/)
Is there something wrong with MSVC 6?
Yes. Well, it's not actually anything intrinsically wrong with VC6, but Microsoft has managed to cripple it. All new Platform SDKs are now using a library format that is incompatible with VC6's linker.

So now if an application wants to take advantage of some of the newest Platform SDK functionality (e.g. stuff that's new in Vista), VC6 will likely not be able to link with the required libraries.

I doubt that there was anything that absolutely needed to be changed with regard to the library format. I'm of the opinion that this was a carefully crafted Microsoft strategy to force developers to stop using VC6 (which is the oldest Visual Studio release that still has a large number of active users).
[ Parent ]
VC6 doesn't work with the new "secure" libs by I'm Don Giovanni (Score:1) Thursday September 29, @06:22AM
Re:VC6 doesn't work with the new "secure" libs by slcdb (Score:3) Thursday September 29, @04:09PM
1 reply beneath your current threshold.
Re:Why bother? by vcv (Score:1) Tuesday September 27, @04:05PM
Re:Why bother? by agm (Score:2) Tuesday September 27, @04:54PM
Re:Why bother? by jerdenn (Score:1) Tuesday September 27, @09:54PM
1 reply beneath your current threshold.
Re:Why bother? by cookd (Score:2) Tuesday September 27, @09:18PM
Re:Why bother? by EvlG (Score:3) Tuesday September 27, @11:47PM
1 reply beneath your current threshold.
Third Way(Score:2)
by mkcmkc (197982) on Tuesday September 27, @04:04PM (#13661770)
The market for programmers seems to be warming up a little. Rather than try to decide between two losing alternatives, maybe it'd be better to just work on your resume...
Mike

Changing compilers is always fun . . .(Score:2, Interesting)
by ChefAndCoder (902506) on Tuesday September 27, @04:38PM (#13662100)
Interface wise, I think the Microsoft dev products are pretty good and I felt they tended to improve with each version. Guessing based on my transition from VC6 to 2003, you shouldn't have too many problems with the new look and feel.
Now, I'm assuming that you're also planning to change the compiler you use in VC6 to whatever they've got for 2005. And this is where things get fun.

At my last job, we switched compilers on two occassions. The first time was a disaster, and our QA team was flooded with defect reports - see, as we did this shortly before a major release and learned a painful lesson.

Recently, we migrated from VC6 to the VC7 compiler. We continued to compile both versions for almost a year before we finally committed to the new compiler. I think the newer compilers are better for error detection in the compilation phase, but you will have to carefully watch out for subtle bugs that don't appear simply because of how the compiler used to behave.

A couple of years ago, there was a great article in Dr. Dobbs about using multiple compilers from different vendors as a great way to help catch errors in your code as well as use safer programming practices. Our migration pain highlighted just how much this one practice could have spared us in the long run.

What benefits are there,(Score:1)
by BlindRobin (768267) on Tuesday September 27, @04:53PM (#13662227)
...and what things do we lose?
why your eternal souls of course

...uhh but then you've already done that... damn!
Headers, STL, linkage(Score:2)
by aminorex (141494) on Tuesday September 27, @05:20PM (#13662420)
(http://slashdot.org/ | Last Journal: Friday May 07, @03:22PM)
These were the biggest areas of pain for me: Header file dependency changes, STL namespace issues, and linking model.

The only benefit I found was smaller object code size. Oh, and debugging is somewhat improved. If you were going full-on .NET the benefits would be substantial, of course.

Why are you upgrading?(Score:4, Insightful)
by Geoffreyerffoeg (729040) on Tuesday September 27, @05:28PM (#13662479)
What benefits are there, and what things do we lose? What problems will occur?"

If you're looking mainly at upgrading the compiler, you can download the command-line compilers for free [microsoft.com] and you can see if it compiles well or not, or if language features you wanted to use are there. These are both the .NET compilers (CSC, VBC, etc.) and the regular compilers (CL, etc.). CL compiles both normal C++ (I've used it on the same code I gave to g++) and Managed (Embraces and) Extensions for C++.

Otherwise you're looking at upgrading the IDE, which is motivated by how much your programmers like or dislike the 6.0 IDE. And if you buy 2005, you're probably going to be upgrading both, so you need to make sure that both will work better (or one better, one as well) as those in 6.0.
Re:Why are you upgrading? by arkanes (Score:2) Wednesday September 28, @08:29AM
Try Visual C++ Toolkit 2003(Score:2, Informative)
by bunratty (545641) on Tuesday September 27, @05:55PM (#13662675)
To get a rough idea of how bad it will be, download MS Visual C++ Toolkit 2003 (available for free) and recompile your code. From my limited experience with porting Visual C++ 6.0 code to Visual C++ 2003, look for lots of compiler errors. Those may be good to fix, though, since the C++ compiler seems to more closely follow the standards, and you'll be forced to make your code more standards compliant and probably more portable, too.
Re:Try Visual C++ Toolkit 2003 by RupW (Score:2) Wednesday September 28, @11:18AM
Been there, done that, no t-shirt.(Score:5, Informative)
by cookd (72933) <douglascook.juno@com> on Tuesday September 27, @08:16PM (#13663466)
(http://students.cs.byu.edu/~cookd/ | Last Journal: Friday May 28, @11:03AM)
I work at MS, and we generally stay on top with compilers. In fact, our new security policies require all shipping code to be compiled with the 7.1 compilers, and pretty soon all code will be required to use 8.0.

I'm the one who upgraded our 2-million line product from 6.0 to 7.1 and from 7.1 to 8.0. In the process, we had about 20,000 compile errors or warnings to fix. I think I was able to fix about 5,000 per week. It was a lot of work, but we actually found bugs and issues in the code. It was certainly worth the effort. Note that we don't actually use the VS IDE to build -- we use the compiler directly from the command line with makefiles.

In general, I would update to the new compiler and turn off all of the new warnings and errors until I got everything building. Then I would re-enable all of the new warnings and work on fixing them. Use the /Zc:forscope- and /Zc:wchar_t- flags at first. One thing to be aware of is that some "errors" are actually warnings that are turned up to "error" status (see the /we flag). These can be changed with the /w flag or with a #pragma warning.

Advantages to the new compiler:

* Better C++ Standards compliance.
* Much better code generation (your program runs faster).
* Many fixed "Internal Compiler Error" issues.
* A few fixed code generation (invalid optimization) issues.
* Many new warnings about things that deserve them.
* Much better debug information.
* Much better handling of templates.

Disadvantages to the new compiler:

* Somewhat slower compile time in some cases.
* Larger PDB (debug symbol) files.

Advantages to new C library:

* Much better C++ compliance.
* Many bugs fixed.
* Better performance.
* Many security fixes.

Disadvantages to new C library:

* Cannot expect runtime to be present on the user's system. (msvcrt.dll and mfc42.dll are already installed on most computers, but msvcr71.dll and mfc71.dll are not).
* Some porting incompatibilities.

Advantages to the new Visual Studio IDE:

* Better Intellisense.
* Support for excellent code coverage, profiling, unit test, and static analysis tools.
* Better debugging.
* Supported (VS 6.0 is 7 years old now -- all support for it is over).

Disadvantages to the new IDE:

* Uses more memory and system resources.
* Beta version has several performance issues. The final version should fix them (cross fingers).

General issues:

* You'll need to recreate your project (*.dsp) and workspace (*.dsw) files.
* Some porting will be required for MFC and ATL apps.
* You may hit one or two CRT changes.
* You may have several thousand warnings or errors. Nearly all of these can be eliminated via compiler flags or #pragmas, but you should really fix them if possible.
* Some CRT functions have been deprecated. You can add a #define to ignore this, but if you care about buffer overflows in your code, you should really take a look at using the "safe" versions.
OT, but you might know... by bmac (Score:3) Tuesday September 27, @09:13PM
Re:OT, but you might know... by cookd (Score:3) Tuesday September 27, @09:26PM
Re:OT, but you might know... by cookd (Score:1) Tuesday September 27, @09:44PM
Re:OT, but you might know... by bmac (Score:2) Tuesday September 27, @10:07PM
Re:OT, but you might know... by cookd (Score:1) Tuesday September 27, @10:21PM
Re:Been there, done that, no t-shirt. by NullProg (Score:2) Wednesday September 28, @09:11AM
Re:Been there, done that, no t-shirt. by RupW (Score:2) Wednesday September 28, @11:28AM
Re:Been there, done that, no t-shirt. by cookd (Score:1) Wednesday September 28, @12:50PM
Re:Been there, done that, no t-shirt. by NullProg (Score:2) Wednesday September 28, @07:08PM
Re:Been there, done that, no t-shirt. by cookd (Score:1) Wednesday September 28, @07:41PM
So, when will there be a native 64 bit IDE? by tjstork (Score:2) Thursday September 29, @11:36AM
Re:So, when will there be a native 64 bit IDE? by cookd (Score:1) Thursday September 29, @01:07PM
1 reply beneath your current threshold.
Do it!(Score:1)
by mario contestabile (906975) on Tuesday September 27, @08:19PM (#13663474)
(http://bubbler.net/outlaw/blog)
If only for the better debugger...vc6 is what, 10 years old? I went (on a large scale app) from vc6->vc7.1 for our production code. You'll certainly have more work going from vc6 to vc8 directly. But the project file extensions changed, so its easy to use both your compilers side-by-side. Areas of pita were templates and for() loops and ATL generated unregistering code
You're a madman, and I admire it!(Score:2)
by tjstork (137384) <tbandrow@nOSpaM.mightyware.com> on Thursday September 29, @11:29AM (#13677082)
(http://www.storkyak.com/ | Last Journal: Monday September 05, @12:12AM)
There were significant changes in how ATL and MFC were used in VC 2002, so, you are going to have touch a fairly big portion of your code. I've found that for 64 bit targets, Visual Studio 2005 is not at all ready for prime time.

My experience from 6 to .NET(Score:1)
by ProZachar (410739) on Friday September 30, @07:56PM (#13690689)
(http://zkissane.2nw.net/)
It's not quite what you're looking for, but here goes:

We use 6 at my work. I have .NET at home. One day I brought a copy of the project home and tried to build it. Errors and warnings abound. I gave up. Of course, my coworkers learned C++ "on the fly" in 1999 with this project and it shows. So if you wrote "good" code and you're not trying to do things you shouldn't be doing, like

enum EnumeratedType {Alpha, Bravo, Charlie, Delta};
CString Text;
EnumeratedType ET = Alpha;
Text = ET; //expecting the text "Alpha" to be in Text

then you should be OK.
(go ahead and laugh, that's in the code MANY times)
(By the way, these are the same people that think SQL databases are for "bad programmers who can't roll their own")
Re:IDE is Beautiful(Score:5, Informative)
by SoCalChris (573049) on Tuesday September 27, @03:07PM (#13661125)
(http://www.lbcpc.com/ | Last Journal: Monday February 21, @11:54AM)
We're using VS2005 for the development of our next gen software here at work (C# though, not C++). VS2005 offers a lot of improvements in the IDE over VS2003, which itself was a huge improvement over the VS6 IDE. Go ahead and try installing VS2005, like the parent poster said, you will likely see large gains in productivity just because of the new IDE and debugging tools available.
[ Parent ]
Re:IDE is Beautiful by forkazoo (Score:3) Tuesday September 27, @03:37PM
Re:IDE is Beautiful by cookd (Score:2) Tuesday September 27, @11:22PM
Re:IDE is Beautiful(Score:2)
by drakaan (688386) on Tuesday September 27, @03:07PM (#13661127)
(http://www.myspace.com/chrisstovall | Last Journal: Thursday September 15, @05:29PM)
Gonna have to go ahead and disagree with you on that one. The VS.Net IDE worked so much differently from previous versions that it slowed me down a fair bit (habits and all, I guess).
Then, of course, there's the fact that a fair number of methods and common constructors from VB6 don't get translated automatically (you'll find out all about this if you have any code that touches any system logs).

I'd say that much code going from VS6 to VS2005 is going to be a rather large pain in the ass, unless Microsoft has made some serious improvements to their project upgrade wizards.

[ Parent ]
Re:IDE is Beautiful by ncmusic (Score:1) Tuesday September 27, @03:18PM
Re:IDE is Beautiful by drakaan (Score:2) Saturday October 01, @04:35PM
Re:VB.Net is NOT VB 7(Score:3, Informative)
by twoflower (24166) on Tuesday September 27, @03:19PM (#13661254)
It's kind of like an san script to english translator.
Never heard of "san script". "Bash script", maybe. You probably meant "sanskrit". HTH, HAND.
[ Parent ]
Re:VB.Net is NOT VB 7 by RingDev (Score:2) Tuesday September 27, @03:35PM
Whoops(Score:2)
by RingDev (879105) on Tuesday September 27, @03:21PM (#13661268)
(http://www.ringdev.com/ | Last Journal: Friday February 03, @01:29PM)
Just saw you said VC, not VB. Not quite as bad in the conversion that way as you should already be using OO design. -Rick
[ Parent ]
Re:VB.Net is NOT VB 7(Score:1)
by Kosgrove (75723) <jkodroff.mail@com> on Wednesday September 28, @10:25AM (#13667159)
You are completely offtopic (as am I in responding), but you're also incorrect. VB.NET (.NET framework 1.x) is VB7, just as .NET Framework 2.x is VB8. It's even referred to that way in MSDN white papers. However, you are correct in your observations about MSFT breaking backwards compatibility in VB.NET and the crappyness of the converter. While the version is labelled 7, it might as well be a whole new language.