Prev: Does Visual Studio 2008 synchronize printf
Next: Mailing follow-ups (was: Re: VC++ 6.0 vs VC++ 8.0)
From: Nobody on 31 Mar 2010 10:40 I have used VC in a limited fashion, typically making DLL's for use by other languages. One thing I noticed is that MS didn't improve VC by much in the unmanaged code area, except by improving standard compliance like others said. In the IDE, the most significant improvement that I noticed is multi-tabs, which makes it easier to switch between source files, and therefore improve productivity. MS seems to have focused on making the IDE better for dotnet based projects. Making managed apps is almost as easy as making them in VB or C#. However, my main thing with dotnet based apps is that they use more resources than an unmanaged solution. While this is not a big deal for single desktops, it could be a problem for terminal servers or Citrix, because each copy of the app would require more memory, and there could be 20 to 50 copies of the same app running on a single server, so multiply memory usage by 20 to 50. However, with 64-Bit OS'es, memory can go beyond 4 GB. One problem that you might encounter is if ATL was used, you need to make some changes to make it work in later versions because ATL library used coding constructs that are not standard compliant. So you need to make some changes. You will get many compilation warning and errors. Googling these errors would show the solution.
From: Giovanni Dicanio on 31 Mar 2010 11:51 "Nobody" <nobody(a)nobody.com> ha scritto nel messaggio news:unM8tAO0KHA.3676(a)TK2MSFTNGP05.phx.gbl... > In the IDE, the most significant improvement that I noticed is multi-tabs, > which makes it easier to switch between source files, and therefore > improve productivity. There is WndTabs, which is a freely available download for VC6 IDE, offering a similar feature: http://www.wndtabs.com/ Giovanni
From: Stephan T. Lavavej [MSFT] on 31 Mar 2010 17:24 > One thing I noticed is that MS didn't improve VC by much in the unmanaged > code area If you care about native code, perhaps you should call it native code. Stephan T. Lavavej Visual C++ Libraries Developer "Nobody" <nobody(a)nobody.com> wrote in message news:unM8tAO0KHA.3676(a)TK2MSFTNGP05.phx.gbl... >I have used VC in a limited fashion, typically making DLL's for use by >other languages. One thing I noticed is that MS didn't improve VC by much >in the unmanaged code area, except by improving standard compliance like >others said. In the IDE, the most significant improvement that I noticed is >multi-tabs, which makes it easier to switch between source files, and >therefore improve productivity. > > MS seems to have focused on making the IDE better for dotnet based > projects. Making managed apps is almost as easy as making them in VB or > C#. However, my main thing with dotnet based apps is that they use more > resources than an unmanaged solution. While this is not a big deal for > single desktops, it could be a problem for terminal servers or Citrix, > because each copy of the app would require more memory, and there could be > 20 to 50 copies of the same app running on a single server, so multiply > memory usage by 20 to 50. However, with 64-Bit OS'es, memory can go beyond > 4 GB. > > One problem that you might encounter is if ATL was used, you need to make > some changes to make it work in later versions because ATL library used > coding constructs that are not standard compliant. So you need to make > some changes. You will get many compilation warning and errors. Googling > these errors would show the solution. > >
From: Pavel A. on 31 Mar 2010 20:26 "verappan" <alvyn(a)gawab.com> wrote in message news:be3ceb94-1f58-45ea-8876-de89c5a63dd7(a)w29g2000prg.googlegroups.com... > I got some points for the discussion :) Perhaps not enough. Challenging your boss is not the best way to start a job. You may find this article useful: http://msdn.microsoft.com/en-us/library/cc265073.aspx By the way - "VC 8.0" is Visual Studio 2005 (compiler versions 14.*) VC 9.0 is Visual Studio 2008 (compiler versions 15.*) Good luck, --pa
From: Liviu on 31 Mar 2010 21:12
"Richard" <legalize+jeeves(a)mail.xmission.com> wrote... > "Liviu" <lab2k1(a)gmail.c0m> spake the secret code ... thusly: > >> I am aware of devenv (and vcbuild/etc), but it's not the same thing. >> For a quibble, but in my experience the command-line devenv builds >> slower at the cmd line vs. the exact same build run from the IDE. > > Are you counting the time it takes to launch the IDE? Otherwise its > not a fair comparison. No, both the IDE and the cmd prompt are already lauched and ready to build. Fair or not, that's my most common use-case scenario. Besides, I don't see much of an initial delay at the cmd prompt when starting the build, so I guess loading devenv itself doesn't weigh much. >>The other distinction is that a makefile is an open, documented >>"blueprint" of the build, and a normal part of a source distribution. > > vcproj and sln files are a normal part of source distribution. Yes, of course, but that's irrelevant to the point I was making. The vcproj file does _not_ contain (officially published) information about how the settings translate to the (well documented) compiler/linker switches. If all I had was a 3rd party vcproj file, and wondered whether the module was compiled with, say, /EHsc vs. /EHa, that's not apparent in the vcproj alone, unless either (a) I have the matching version of the IDE available, or (b) rely on unofficial second guesses. With a makefile, that info is in plain text, plain sight. > I've been using VS since VC6 (1998) and I've never needed Makefiles As I said in my first post, I do realize that this is of little interest to most, yet may still matter to some. Liviu |