Slashdot Mirror


Migrating from MSVC 6.0 to Studio 2005?

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?"

4 of 130 comments (clear)

  1. Very poor by feebdaed · · Score: 5, Informative

    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.

    1. Re:Very poor by bushidocoder · · Score: 5, Informative
      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.

  2. Go for it by frank2 · · Score: 5, Informative

    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$.

  3. Been there, done that, no t-shirt. by cookd · · Score: 5, Informative

    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.

    --
    Time flies like an arrow. Fruit flies like a banana.