VC++ 6.0 vs VC++ 8.0
in [Visual C]
|
Prev: Does Visual Studio 2008 synchronize printf
Next: Mailing follow-ups (was: Re: VC++ 6.0 vs VC++ 8.0)
From: Richard on 2 Apr 2010 13:48 [Please do not mail me a copy of your followup] "Liviu" <lab2k1(a)gmail.c0m> spake the secret code <uPRvHbW0KHA.3708(a)TK2MSFTNGP02.phx.gbl> thusly: > >"Richard" <legalize+jeeves(a)mail.xmission.com> wrote... >> "Liviu" <lab2k1(a)gmail.c0m> spake the secret code ... thusly: >> >>> Curiosity, of course ;-) Well, sometimes more serious reasons, too. >>> An example at random, in the v7.1 IDE there was one setting for >>> "floating point consistency" with two choices. In the v8 IDE there >>> were two related options with more choices under a different tab. >>> Now suppose you had to convert an older project from v7.1 to v8, >>> had only v8 installed, wondered what the old options were before, >>> and how the "conversion wizard" magically mapped them. The old >>> vcproj alone doesn't tell you that. A makefile makes it obvious. >> >> OK, this is an example of the curiosity case. >> What about the serious reason case? > >That was actually an example of the "more serious" part. I'm still not seeing the problem you're solving here, other than satisfying your curiosity. >If you generally go by the builtin/wizard defaults, then you'll be safe, >since I guess that's one primary concern for MS when deciding and >testing the project conversion options. Nope, I've got plenty of projects that don't use default settings that I've upgraded to newere versions. Since I've faced the same issues and never needed to know what you want to know, clearly I've solved it in different ways and that is all I'm saying: knowing the details of the vcproj file is not the only way to solve this problem. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
From: Bronek Kozicki on 3 Apr 2010 05:45 On 30/03/2010 06:59, verappan wrote: > I asked to our team about upgrading 6.0 to 8.0 and I don't get a good > reponse for that. > The project manager told that there no much difference between 6.0 and > 8.0. VC6 isn't supported by many 3rd party C++ libraries any more, e.g. boost. This is because it does not support standard C++ - it only supports its own pre-standard (i.e. pre-1998) flavour of the language. Moving on, C++ programs built with VC8 do NOT require .NET runtime, unless the developer does not care to select Win32 project type and defaults to C++/CLI (which actually is NOT C++). Next: C++ standard library implementation bundled with VC6 has some bugs (fixed long time ago, but these fixes aren't available to VC6 users). This is important unless the team does not use C++ standard library (and it's not real-time or kernel programming because VC6 is not suitable for those anyway). In which case I would run away from such team screaming. While we are at it, the following might be good evaluation of programming skills of the local team : find how many "catch(...)" are there in the codebase. Why does this matter? http://programmer.97things.oreilly.com/wiki/index.php/Don't_Nail_Your_Program_into_the_Upright_Position B.
From: Liviu on 3 Apr 2010 14:23 "Richard" <legalize+jeeves(a)mail.xmission.com> wrote... > "Liviu" <lab2k1(a)gmail.c0m> spake the secret code ... thusly: >>"Richard" <legalize+jeeves(a)mail.xmission.com> wrote... >>> "Liviu" <lab2k1(a)gmail.c0m> spake the secret code ... thusly: >>> >>>> Curiosity, of course ;-) Well, sometimes more serious reasons, too. >>>> An example at random, in the v7.1 IDE there was one setting for >>>> "floating point consistency" with two choices. In the v8 IDE there >>>> were two related options with more choices under a different tab. >>>> Now suppose you had to convert an older project from v7.1 to v8, >>>> had only v8 installed, wondered what the old options were before, >>>> and how the "conversion wizard" magically mapped them. The old >>>> vcproj alone doesn't tell you that. A makefile makes it obvious. >>> >>> OK, this is an example of the curiosity case. >>> What about the serious reason case? >> >>That was actually an example of the "more serious" part. > > I'm still not seeing the problem you're solving here, other than > satisfying your curiosity. Generally speaking, traditional makefiles have been around for a long time and some of us, at least, find them useful, more readable, and better documented than the opaque vcproj files. At the risk of repeating the same example, makefiles are still used by MS itself with the source distribution of their own CRT/ATL/MFC libraries. For a particular case where the f/p options matter, see for example <http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/7fde034a-9e1e-4675-a25c-ac416f5c0856> where the OP was able to narrow it down to /Op- vs. /fp:precise, making his question more meaningful and easier to answer. Liviu P.S. Now, for a (loosely related) trick case... Suppose you create a new empty Win32 project in v7.1 and add one floateq.c file to it. /* floateq.c */ #include <stdio.h> double g() { return 123456789.; } int f() { return (float)g() == (float)g(); } void main() { printf("f() = %d\n", f()); } /* end of floateq.c */ With the default project options, the debug build will print "f() = 0". Then, import the project into v9, rebuild, run, and it will now print "f() = 1". Assume you don't happen to have the old v7.1 installed or available, so all you have to work with is the old vcproj file. Would you guess that (a) the project conversion wizard failed to carry over some relevant setting, (b) the old compiler was broken, or (c) none of the above. Incidentally, the answer is (c) but that's far easier to figure out if you know the exact command line of the v7.1 compiler as opposed to just second-guessing the vcproj.
From: Liviu on 3 Apr 2010 14:27 "Pavel A." <pavel_a(a)12fastmail34.fm> wrote... > "Tim Roberts" <timr(a)probo.com> wrote... >> Have you every tried to make bulk changes to a set of vcproj files? >> I don't want to wear my fingers out by clicking over and over [...] > > Why making a bulk change to several vcproj's is harder than changing > several makefiles? They are plain text. It's not necessarily harder, and (not speaking for Tim, but IMHO) it's not a matter of how hard it is, anyway. The build process needs to be documented and understandable _even_ if the host environment is not available - or if one doesn't appreciate having to click around all those property pages. The good old makefiles provided the transparency, the newfangled vcproj's don't. That's all. Liviu
From: Tim Roberts on 3 Apr 2010 23:47
"Pavel A." <pavel_a(a)12fastmail34.fm> wrote: > >Why making a bulk change to several vcproj's is harder than changing several >makefiles? >They are plain text. Find & replace, or write a script.... It's NOT harder. You completely missed the point. I'd PREFER to edit my vcproj's by hand, but (to the best of my knowledge), there is no concise reference that tells me what the numbers in the vcproj files mean. I found an XML schema for the Visual Studio 2002 vcproj files, but even that didn't tell what the numbers meant. >And, have you tried property sheets? >In a property sheet you can define environment variables for external >tools, extra includes, libs and makefile commands. Nope, but I'll look them up this week... -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc. |