Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Microsoft Upgrades IT Technology

Migrating from MSVC 6.0 to Studio 2005? 130

Posted by Cliff 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? More

Migrating from MSVC 6.0 to Studio 2005?

Comments Filter:

  • what? concerns about MS compatibility? (Score:4, Funny)

    by yagu ( 721525 ) * <yayagu.gmail@com> on Tuesday September 27, 2005 @02:43PM (#13660902) Journal

    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?

    Nope, only work related experience.
    Sorry I couldn't help.

  • .Net 2 (Score:3, Informative)

    by Fr05t ( 69968 ) on Tuesday September 27, 2005 @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 (Score:3, Informative)

      by Surye ( 580125 )
      You can, you have to set a compiler flag for old syntax and 1.1
      • I'll have to check it out again then. At the time there were only crazy half baked hacks people had put together. If MS has given it better support I may switch over since I found it to be a pretty good improvement over VS2003.

        Thanks for the info.
    • It would be a non-issue. If he's moving from VS 6.0, he isn't using .NET at all.

  • Comments are for wimps. (Score:2, Funny)

    by Anonymous Coward

    grep -v -e "^\/\/" oldfoo.c > newfoo.c

  • Very poor (Score:5, Informative)

    by feebdaed ( 146792 ) on Tuesday September 27, 2005 @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 (Score:3, Insightful)

      by Keith Russell ( 4440 ) *

      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.

      Are you sure that wasn't just early-beta cruft? Microsoft has been making a push for C and C++ standards compliance with VS2k3 and 2k5. And if functions like strlen() are failing, I doubt Microsoft would be able to use the compiler as dogfood.

      • Re:Very poor (Score:5, Informative)

        by bushidocoder ( 550265 ) on Tuesday September 27, 2005 @03:36PM (#13661464) Homepage
        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.

        • Re:Very poor (Score:3, Informative)

          by ckelly5 ( 688986 )
          I'd also like to add to this that if you read the msdn article "Saying Goodbye to an old friend", Microsoft has submitted the new "safe" methods (called "strsafe functions") to the C/ C++ standards committee to have them included in future versions of C++

          "say goodbye":
          http://msdn.microsoft.com/library/default.asp?url= /library/en-us/dncode/html/secure03102004.asp [microsoft.com]

          more info on strsafe.h (included in the VC.NET 2003 SDKs and up):
          http://msdn.microsoft.com/library/default.asp?url= /library/en-us/dnsecu [microsoft.com]
        • I can see why a function like strcpy, which writes to memory, is unsafe, because it can keep writing forever if there is no terminating zero in the source string. But strlen is unsafe? Why? At most it will consume CPU when counting an unterminated string. It's implemented somehow like this: for (n = 0; *str; n++) str++; If the string is unterminated, eventually this function will segfault, but I cannot see any bigger harm done.
          • Three issues:

            1. Resources. It might slow down the system while scanning for the nul.
            2. SegFault is still not a good idea.
            3. Most important: The result from strlen gets used elsewhere. If the string is unterminated, you've just put a large random number into your code. Somebody else might assume that the result from strlen is a reasonable size (10-20 bytes), when it really is more like 10k, and you weren't prepared for a 10k string.

          • There's an easy workaround. What you do is this:

            size_t length_bound = strlen(my_string);<br>
            size_t length = strlen_s(my_string, length_bound);

            This handy snippet adapts readily to strings of any size, while still reporting the length of your string accurately using the safe

            strlen_s
            function.

            HTH. HAND. :-)

        • Re:Very poor (Score:3, Informative)

          by jmccay ( 70985 )
          I find that funny. I just compiled a short sample using VS 2005 Beta 2 team edition with no problems using strlen. I think the string.h versions were deprecated, but cstring header should not be considering it is a part of the standard. I tried both cstring & string.h. What version of the beta do you have.
    • No, there's another way around that. Set the compiler to ignore those warnings. I don't have VS2005 available right now, but I just did it last night on a newly converted project.
    • The problem with VS 2003 is that the warning levels are very coarse grained. You either get nothing, or an avalanche of both trivial and non-trivial warnings. Maybe in 2005 the default is just stricter. And is strlen() deprecated in favor of something like strnlen, or is it just deprecated with no replacement?

      • Re:Very poor (Score:2, Informative)

        by thsths ( 31372 )
        > And is strlen() deprecated in favor of something like strnlen, or is it just deprecated with no replacement?

        How is strnlen() a replacement for strlen()? Sure, if you have fixed length storage, it may do, but for dynamic strings it just doesn't work. Plus strnlen() is not conforming to any standard, so you cannot rely on the behaviour being portable.

        • Re:Very poor (Score:2, Interesting)

          by Anonymous Coward
          You're coding in Visual Studio, to paraphrase: "We don't need no steenking portability!"
      • Actually, you can do whatever you want with the warnings.

        Every warning has a default level, either "error", "1", "2", "3", "4", or disabled. You can change the level of any warning. You do this via #pragma warning. Typically, you will create a customized "warning.h" file that has all of your warning settings, and you will include it into your compile with the /FI(file) command line option.

        Like a warning? Promote it to level "1" or make it an error. Don't like a warning? Make it level "4" or disable it
    • No, you have to enable linking to the old libraries using the Tools -> Options -> Folders thing, do libraries, and point it to the Platform SDK ones. Then you'll have good ol' c/c++ and win32. It was a feature left out in the early .NET 2005 Beta's that really pissed me off.
    • 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.

      Uh, no, it's a define: _CRT_SECURE_NO_DEPRECATE. The warning message actually tells you that. Or at least it does in beta2 and beyond.

      And it's not necessarily lockin: MS have proposed the *_s versions to the C committee, I think.

    • It's strange that you have that experience, because we've ported several code bases of comparable size to the beta with no such difficulties. It took a few minutes to deal with warnings about deprecated functions, but there weren't many since in C++ there aren't many reasons to prefer C-style strings over a decent class anyway.

      What were the errors you saw?

  • 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 )
    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.
    • If you judge a compiler by how it upholds language standards (builds legitimate C++ code, STL implementation etc) then MSVC++ 6.0 is terrible.

      Google for "enum hack" (static const int foo = 42; doesn't work in a header file.) to learn about the fun of writing workaround code to get around MSVC++ 6.0s deficiencies.
    • ] if 6.0 to 2003 is any indication Get ready for a lot of manual header adding.

      Work smarter, not harder.

      i.e. There are utils/macros to do that, specfically, you'll want to check out...

      1. Project Converter [codeproject.com]
      2. .NET 7 <--> .NET 7.1 [codeproject.com]

      --
      If the Bible is infallible, which version would that be?

  • One Tip... (Score:5, Funny)

    by GypC ( 7592 ) on Tuesday September 27, 2005 @03:00PM (#13661061) Homepage Journal
    ... 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, 2005 @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.
    • Have you tried using precompiled headers for the VS Build ??
      Cut our build and link times down by a huge percentage for a 500,000+ SLOC cross compiled project
      (linux-gcc) and MSVC++ 2003.NET
      I havent looked at precompiled headers for the Linux build but on the Win32
      side of things it helped a lot
      nice article here [gamesfromwithin.com]
    • This usually is from Link-Time-Code-Generation. This is a nifty optimization that can make a big difference in some cases, but it makes linking take a lot longer.

      Remove the /GL flag from the compile, and remove the /LTCG flag from link. Your build times should go down significantly.

  • Some unfixed bugs still ... (Score:5, Funny)

    by twoflower ( 24166 ) on Tuesday September 27, 2005 @03:07PM (#13661120)
    What problems will occur?
    Make sure you read KB3090309, "KNOWN ISSUE: Earth crashes into Sun" before upgrading.

  • You should be fine.. (Score:4, Informative)

    by parryFromIndia ( 687708 ) on Tuesday September 27, 2005 @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.

  • Sloppy Programming will cause issues (Score:3, Informative)

    by KMAPSRULE ( 639889 ) on Tuesday September 27, 2005 @03:07PM (#13661131)
    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
    • There's nothing wrong with that code, although I personally would try to avoid writing like that too. But there _IS_ a thing called "scope" in C/C++ which allows it. Older M$ compilers didn't understand scope properly though, and this caused big problems. There is an option in VS2005 to enable/disable scope enforcement though (sorry - don't have VS2005 available in front of me to check out where it's located at).
      • Yeah ... there were _HUGE_ blocks of code in the application that we inherited that pretty much ignored scope
        MVSC++ 6.0 let most of it slide, bit us hard when we took it to 2003 .NET and there were a few places that had wacky scoping that
        didnt cause an issue till we tried 2005. NET, we are still aways away from transitioning from 2003.NET but if the previous owners of the Code had
        tried to follow the standards and had followed good coding practices there wouldnt have been as many issues when we compiled w
      • There's nothing wrong with that code,[...]

        You mean, other than using a variable outside its scope?
    • The problem is the compiler, not practice.

      If you do a lot of loops, it makes sense to reuse the "i" variable, since it's been a standard iterator name since the days of Fortran in the 60's.

      The old compiler (VC6, which I use by the way) didn't recognize variables declared in the for clause as existing only within the scope of the for loop.

      So what do you do?

      1. Use a different variable name for each loop. Granted sometimes this makes sense. I find myself more and more using short descriptive names anyway, b
      • So what do you do?
        1. Use a different variable name for each loop. [...]
        2. Do exactly what you describe, and reuse i over and over even though it's incorrect.
        And what, pray tell, is wrong with doing it the valid, old-fashioned way? I.e.:
        int i;
        for (i=0; i<MAX_A; i++)
        {
        do_something(i);
        }
        for (i=0; i<MAX_B; i++)
        {
        do_something_else(i);
        }
        • Duh. Nothing. I'm so used to declaring in the for loop I didn't even consider the goold old C way.

          Duh.

        • That's great as long as things don't get complicated. Declaring i in the outer scope like that is a temptation to use it in that outer scope. (Like not declaring things const.) For example, what if you have this:

          int i;
          for (i=0; i<MAX_A; i++)
          {
          do_something(i);
          if (condition) break;
          }
          ...
          if (i==...) {...}

          No problem, right? But say a year later, you come along and find that you need to modify your code to something like this:

          int i;
          for (i=0; i<MAX_A; i++)
          {
          do_something(i);
          if (condition) break;
          }
          ...
          for (i

          • Okay then,
            for (int i = 0; i < MAX_A; ++i) {
                do_something (i);
                if (condition) break;
            }
            /*...*/
            for (int i = 0; i < MAX_B; ++i) {
                do_something_else (i);
            }
            100% standards-compliant C++, and no risk of using i outside the loop. What's the problem?
            • Exactly so. Your code is the proper way to do it. I was replying to: "And what, pray tell, is wrong with doing it the valid, old-fashioned [C not C++] way?" My above code illustrates exactly what is wrong with the C way.

              The only real issue left with the proper C++ way (that you illustrate) is that VC6 was broken, and a good portion of the world's C++ code couldn't use it.
            • What's the problem?

              MSVC6 will claim that i is declared twice. That's what we are talking about. There doesn't seem to be a good way to handle this for code that is compiled under the old bad way and the newer good way of interpreting scope for the for loop variables.

              I have a huge library of code that I use with MSVC++6. Some day I imagine a client will actually want to use VC2003 or newer (hasn't happened yet). I'd rather use the new style as it is (and always has been) the correct implementation for C+
        • It's bad practice to reuse the variable. (I'm sure many books have reiterated this, but Code Complete by Steve McConnell comes to mind as a place where I definitely remember reading this.) Performance-wise, it will not make any significant difference, but in terms of readability and correctness, if those loops are 40 lines apart, you're going to have a tougher time debugging and a much greater risk of making a logical error. The best practice is to declare a variable right before it's used, and to use it
      • People seem to forget that you can create scopes at will.

        void myfunc()
        {
        { // Scope for the "i" variable.
        for (int i = 0; i < 10; i++)
        {
        ...
        }
        }

        { // Scope for the "i" variable.
        for (int i = 0; i < 10; i++)
        {
        ...
        }
        • Actually, I mentioned that, but don't like it because it's just more clutter. You're still working for the compiler rather than the other way around.

          I think it all boils down to a short-sighted (at least in hindsight) choice made by the implementors of the original C++ compilers and wasn't corrected until the standard was actually passed and people like Microsoft made a concerted effort to follow the standard to the fullest. From what I've heard VC++ 2003 is among the best, if not the best, at fully and c
      • The old compiler (VC6, which I use by the way) didn't recognize variables declared in the for clause as existing only within the scope of the for loop.

        This is a documented Microsoft syntax extension. You can disable it with /Za.

  • Migration Problems (Score:3, Insightful)

    by megaversal ( 229407 ) on Tuesday September 27, 2005 @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, 2005 @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$.

  • VC++ 2005 issues for embedded developers (Score:3, Informative)

    by demigod2k ( 471203 ) on Tuesday September 27, 2005 @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.

  • If it ain't broke... (Score:3, Insightful)

    by N7DR ( 536428 ) on Tuesday September 27, 2005 @03:30PM (#13661379) Homepage
    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

  • Why bother? (Score:4, Insightful)

    by DavidYaw ( 447706 ) on Tuesday September 27, 2005 @03:31PM (#13661398) Homepage
    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? (Score:2, Informative)

      by frank2 ( 63179 )
      Because VC6 generates poor code for today's CPU's. Numerous issues which are generally only known to assembly language geeks or compiler writers cause the code to not work as efficiently as possible. Our rendering code under VC2005 executes on average in about 2/3 the time that it does under VC6. How much is a CPU/system upgrade going to cost you to get that kind of performance gain??? ;)
      • Also, VC6 is not very good with C++ standard compliance. Moving forward should let you have a lot more flexibility with third party library availability.

    • Re:Why bother? (Score:5, Interesting)

      by slcdb ( 317433 ) on Tuesday September 27, 2005 @04:02PM (#13661740) Homepage
      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).
    • Better Performance. Better productivity in the IDE.
    • I bought "Visual Studio.net C++ 2003" because I needed to buy a copy for a financially quite rewarding contract. I avoid MS solutions as much as I can (and run Gentoo everywhere) but with the $$ on offer I had little issue with paying for a copy of XP and "VS.net C++ 2003" (all running under VMWare on Gentoo of course). The problem was I could not purchase Visual Studio 6 (which I am familiar with). No one would sell one, so I had no choice but to buy the latest version (or break the law, which I won't do w
      • Visual Studio 6.0 comes with an MSDN subscription, so yes, you could have purchased this software. However, it would have cost quite a bit more than VS.NET C++ Standard Edition (2003).

    • Re:Why bother? (Score:2, Insightful)

      by cookd ( 72933 )
      VC 6 was released in 98. Do you develop apps for the latest version of Linux with GCC 2.8 (VC 6's contemporary) and GLibC 2.0.7? If you're targeting older platforms (Windows 98), I could see why you might want to stick with VC 6. But otherwise, use the best tool for the job.

      Since VC was released, there have been 7 years of bug fixes and improvements to the compiler. Lots of new optimizations, warnings, and security features. Not all of them are trivial. And the runtime has had a lot of work -- much cl

    • Re:Why bother? (Score:3, Interesting)

      by EvlG ( 24576 )
      Visual Studio 2005 also includes a new feature called Profile Guided Optimization.

      This feature allows you to make a special build of your program which instruments your code with performance metrics gathering code. You run your program and it automatically gathers a bunch of data. Then you rebuild the program and the compiler looks at the performance metrics and can make special optimizations targeted at your application.

      I spoke with the developers about this feature and they quoted a 20-30% speedup in Yuko
  • 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

  • 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 defe

  • ...and what things do we lose?
    why your eternal souls of course



    ...uhh but then you've already done that... damn!
  • 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, 2005 @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.
    • It's nominally possible to use the toolkit as a drop in replacement for the C++ 6.0 tools, while still using the VC 6 IDE, but you'll lose debugging because VC 6 can't read the debugging info the 2003/7 compiler generates.

      VC 2005 is all around superior to VC 6 in pretty much every way and there's not really any good reason not to switch other than inertia. You get a better compiler, a better IDE, better standards compliance, etc.

  • 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.
    • Anyone can get hold of an 'express' edition [microsoft.com] of the whole IDE for free - there's no reason to judge it on the 2003 compiler.

      And if they're a serious Windows dev shop they'll probably have an MSDN subscription and already have access to the new version anyway.

  • Been there, done that, no t-shirt. (Score:5, Informative)

    by cookd ( 72933 ) <douglascook@NOSpaM.juno.com> on Tuesday September 27, 2005 @08:16PM (#13663466) Journal
    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... (Score:3, Interesting)

      by bmac ( 51623 )
      I've been trying to build a c++ app w/ the original VS Studio .NET, and I'd really like to not link to the standard C libs at all (like libc.lib). I'd really like to just link to the main three: kernel32.lib, user32.lib and gdi32.lib. I've tried /NODEFAULTLIB but that leaves me hanging with a handful of unresolved linker refs to what appears to be auto-generated fct calls (like _RTC_CheckEsp and ___CxxFrameHandler).

      Do you know if I can do a clean link to just the "main 3"?

      I would really appreciate the hel
      • Yes, you can. You just have to disable the compiler features that correspond to the function calls you don't want.

        _RTC_CheckEsp comes from the /GZ or /RTCs compiler switches. Turn off the "Runtime Checks" options.

        ___CxxFrameHandler comes from /GX or /EH??. Turn off the "Exception Handling" options.

        With more recent versions, you might see something about "security_cookie". For that, turn off the buffer overflow detection (/GS).

        Good luck!
        • Another thing to keep in mind that when you do this, your program's "Entry Point" is NOT "int main(char**, int)" or "int WinMain(HINSTANCE, HINSTANCE, LPSTR, int)". The raw entry point is simply "int MyEntryPoint()" with NO parameters (name doesn't matter since you just pass the name of the entry point to the linker). You can call it main or WinMain, and you can specify whatever parameters you want, but the parameters won't be initialized.

          Normally, the CRT provides the raw entry point, initializes itself
    • * You may hit one or two CRT changes.
      Please explain the CRT changes or point me to an article on MSDN.

      * 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.
      Our software is O/S and CPU agnostic. It runs under Unix and Windows and all the primary logic routines are written in C/C++. Are you saying that Microsoft broke the standard C libary? Why not just patch the msvcrt.
      • Are you saying that Microsoft broke the standard C libary?

        No, they're trying to convince you to use safer versions of the functions with extra parameters. You get a warning

        This function or variable may be unsafe. Consider using strnset_s instead. To disable deprecation, use _CRT_SECURE_NO_DEPRECATE. See online help for details.

        They've proposed all the new *_s versions to the C standards committee, I think - they're trying to improve things rather than lock everyone in. In general the functions just add an e

    • It's kinda hard to trust a tool for 64 bit development when it itself is not 64 bit.
  • 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
  • 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.

Slashdot Top Deals

You know you've landed gear-up when it takes full power to taxi.

Close