VC++ 6.0 vs VC++ 8.0

Post by verappan
I am a fresher in VC++ and I joined a new company where the
development environment is Visual Studio 6.0.
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.

That rings an alert bell. VC6 even predates the C++ standard and in many
aspects doesn't adhere to it. It's not supported by the vendor any longer,
too. I'd expect such a statement from someone who doesn't know much C++ and
for sure is not up to date with his or her knowledge of it.

Post by verappan
Also I got the information from other team members that, if the
application is developed in VC++ 6.0, then there will not be much
dependencies on the output EXE and no need to install .Net Runtime
environment to run the EXE.

You also don't need a .Net runtime when developing with VC8, unless of
course you want to.

Uli

--
C++ FAQ: http://parashift.com/c++-faq-lite

Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

Giovanni Dicanio

2010-03-30 09:57:49 UTC

Post by verappan
The project manager told that there no much difference between 6.0 and
8.0.
Anybody please correct me on this, if this is wrong.

That's wrong: there are several improvements in more modern versions (e.g.
more C++ standard compliance, better libraries, etc.)

You can static-link the CRT or MFC libraries with your EXE in VC8 as well,
and so you will not have any dependecies on the output EXE.
And you can write a pure native C++ application in VC8 as well, so you don't
have dependencies on .NET runtime.

Post by verappan
Could anyone pleas provide here the advantages and disadvantages of VC+
+ 6.0 and VC++8.0.

VC++ 8 compiler is much better than VC++ 6 compiler if you want to do cross
platform C++ code, or if you use templates a lot.
I recall that VC6 has some problems with an advanced use of C++ templates.
Moreover, there were some bugs in STL implementation that came with VC6
(you'd better use STLport, or apply some patches from Dinkumware website);
STL implementation of VC8/9 is much better.

If you want to migrate your code base from VC6 to VC8 you will have some
cost, but after migration you could enjoy a better compiler and better
libraries.

If your app uses MFC, when you move from VC6 to VC8 you will miss great
ClassWizard. But note that VC6-style ClassWizard is back in VS2010!

Moreover, the latest Windows Platform SDK supported by VC6 is something from
February 2003. So, if you want to use the new cool features of Windows 7,
you must upgrade to a more modern version of the compiler.

Giovanni

Jochen Kalmbach [MVP]

2010-03-30 09:06:25 UTC

Hi verappan!

A small addition to the other postings:

- Applications build with VC6 will run on any OS, starting from Win95.
- Applications build with VC( will only run on W2k-SP4 and later.
- I would currently not recommend to upgrade to VC8, because of the
WinSxS hell (Side-by-Side problematic)
- I would upgrade to VS2010 on April, 12th
- VS2010 will use the "normal" DLL-Hell
- Hopefully the VS2010 IDE will have not too much bugs, because it is
mostly rewritten
- I would also upgrade to VS2010 because of the ClassWizard

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

PvdG42

2010-03-30 15:23:59 UTC

Post by verappan
Dear friends,
I am a fresher in VC++ and I joined a new company where the
development environment is Visual Studio 6.0.
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.
Anybody please correct me on this, if this is wrong.
Because strongly believe that 12 yr old application and its upgraded
version contains definitly be huge change.
Also I got the information from other team members that, if the
application is developed in VC++ 6.0, then there will not be much
dependencies on the output EXE and no need to install .Net Runtime
environment to run the EXE.
Could anyone pleas provide here the advantages and disadvantages of VC+
+ 6.0 and VC++8.0.
Thanks and Regards
Vayand

Hello, Vayand.
First, I very much agree with the comments you've received so far. The new
compilers (8 and 9) are far superior to 6.
However, as you say you are new to this company using 6, consider tempering
your enthusiasm with a dose of common sense. In many work environments,
comments, questions and suggestions from "the new guy" are not well
received, even if valid and useful, by the incumbents. Taking it a bit slow
may it possible for you to effect change as an insider.

FWIW, I learned this lesson *many* years ago as a recent graduate on a new
job.

Liviu

2010-03-30 21:54:33 UTC

I second the points made already, most of them about the advantages
of newer versions (better language compliance especially in C++ and
templates areas, more up-to-date libraries, support for the latest
sdk's, active support and maintenance updates from MS etc).

One plus for v6 which wasn't mentioned (and is probably not important to
most users) was the ability to directly export a makefile, so it was
easier to keep builds in sync between the IDE and the command line
(not to mention that the bare v6 compiler binaries could essentially be
xcopy'd to a separate build machine or vm without a full install).

However, back to your question, you don't provide enough details for
a real answer. Just because the newer versions are a decade more recent,
that alone does not make them automatically "better". One example, v10
which is around the corner was dubbed "the new v6", so maybe not all old
version were that bad to begin with ;-) Seriously now, it depends a lot
on what areas your group works in. If for example you develop mostly
C or C++ with little templates then the upgrade may not make a striking
difference. Or, if you depend on other 3rd party libraries tied to
certain versions of the compiler, then the upgrade may even be painful.

The reason you quote other team members for having given you about the
.net dependency is wrong - as pointed already, you can happily build
native/unmanaged applications in all later versions. Yet, the reason you
give for upgrading just because "it's newer" is not very convincing,
either (and won't make you sound too professional, for that matter).
If, instead, you can point out specifics to them e.g. "we could use
covariant return types here, but v6 doesn't support that" you might
stand a better chance to be heard and given due consideration.

Liviu

legalize+ (Richard)

2010-03-31 01:41:33 UTC

[Please do not mail me a copy of your followup]

Post by Liviu
One plus for v6 which wasn't mentioned (and is probably not important to
most users) was the ability to directly export a makefile, so it was
easier to keep builds in sync between the IDE and the command line
(not to mention that the bare v6 compiler binaries could essentially be
xcopy'd to a separate build machine or vm without a full install).

FYI, you don't need a Makefile to do command-line builds. Just run
devenv.com with the appropriate switches. I've run lots of
command-line builds for VS.NET without ever needing a Makefile.

--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

Liviu

2010-03-31 03:04:03 UTC

Post by Liviu
One plus for v6 which wasn't mentioned (and is probably not
important to most users) was the ability to directly export a
makefile, so it was easier to keep builds in sync between the
IDE and the command line (not to mention that the bare v6
compiler binaries could essentially be xcopy'd to a separate
build machine or vm without a full install).

FYI, you don't need a Makefile to do command-line builds. Just run
devenv.com with the appropriate switches. I've run lots of
command-line builds for VS.NET without ever needing a Makefile.

I only said that the v6 option to export a makefile made it _easier_,
not that the v7+ lack thereof made it impossible ;-)

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. It used to be
the reverse case up to v6, with nmake and makefiles which spawned
cl/link/etc directly. But, again, that's just a minor thing.

The other distinction is that a makefile is an open, documented
"blueprint" of the build, and a normal part of a source distribution.
Microsoft's compiler/linker/etc switches (as used in a makefile)
are officially and clearly documented. In contrast, a vcproj file is a
closed-form script of the same build process, but with no official
documentation or changelog between versions. The actual commands
and switches can be looked up in the resulting buildlog.htm, of course,
yet that's not something one would normally consider a source, put
under version control, or include with a source package.

Liviu

verappan

2010-03-31 07:24:57 UTC

Dear friends,

Thanks for the response.
I understand that the latest versions of visual c++ is far supirior
than VC++6.0.
I got some points for the discussion :)
The project I am working is a Medical Image Viewer in win32 and MFC
There is not much usage of templates and there are some 3rd party
libraries inlcuded.
And the client OS(where the output exe is running) is mostly Win2k and
XP.
These are the background of the project that I am working.
As an ethusiastic user, I am still expecting more comments based on
these information.

Thanks and Regards
Vayanad

Pavel A.

2010-04-01 00:26:32 UTC

Post by verappan
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

legalize+ (Richard)

2010-04-01 03:07:22 UTC

[Please do not mail me a copy of your followup]

Post by Pavel A.
http://msdn.microsoft.com/en-us/library/cc265073.aspx

That link seems to show the content without context. Just for the
benefit of others, this is an excerpt from I.M. Wright's book
"Hard Code".

Post by Pavel A.
By the way - "VC 8.0" is Visual Studio 2005 (compiler versions 14.*)
VC 9.0 is Visual Studio 2008 (compiler versions 15.*)

And Visual Studio 2010 is almost out, so if you do end up switching to
a more modern Visual Studio, you might as well switch to that one.

Pavel A.

2010-04-01 12:00:11 UTC

Post by Pavel A.
http://msdn.microsoft.com/en-us/library/cc265073.aspx

That link seems to show the content without context. Just for the
benefit of others, this is an excerpt from I.M. Wright's book
"Hard Code".

[............]

Pardon me... they change the MSDN layout all the time; it was in context
when I've bookmarked it.
Here is a link to the original blog of "I.M.Wrigth" (pseudonym of Eric
Brechner)

http://blogs.msdn.com/eric_brechner/about.aspx

Great advice - wish I found it many o'moons earlier!

Regards,
-- pa

legalize+ (Richard)

2010-03-31 09:42:33 UTC

[Please do not mail me a copy of your followup]

Post by Liviu
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.

Post by Liviu
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. It is
well documented how to build a project or a collection of projects
using command-line switches for devenv. If you're using project
files, you probably aren't opening them in a text editor and changing
text in order to change project settings; you're changing those
settings in the IDE using the GUI. If for some reason you need to
make programmatic changes to projects, you can use the automation
interface and scripts to do that.

I've been using VS since VC6 (1998) and I've never needed Makefiles
for my VS projects. I've automated builds and done all sorts of
things with projects/solutions and never needed Makefiles.

Ulrich Eckhardt

2010-03-31 10:39:11 UTC

Post by legalize+ (Richard)
[Please do not mail me a copy of your followup]

Richard, if you don't want that, you should consider not setting an
explicit Reply-To to your email address. This prevents people from
doing the right thing by just replying.

Cheers! ;)

Uli

--
C++ FAQ: http://parashift.com/c++-faq-lite

Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

legalize+ (Richard)

2010-03-31 21:19:33 UTC

[Please do not mail me a copy of your followup]

Reply-To is for email replies, not for newsgroup followup postings.
If your newsreader doesn't understand standard headers, you should get
a better newsreader.

Liviu

2010-04-01 01:12:09 UTC

Post by Liviu
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.

Post by Liviu
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.

Post by legalize+ (Richard)
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

legalize+ (Richard)

2010-04-01 03:10:10 UTC

[Please do not mail me a copy of your followup]

Post by legalize+ (Richard)
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.

This isn't an apples-to-apples comparison then because you've already
spent the time for the startup of the IDE and loading the solution.
Both of these things have to be done from the command-line.

Post by Liviu
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.

But loading the IDE to do a build *is* expensive and should be counted
if you're going to do comparisons.

Post by Liviu
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.

And yet I feel this is a worthless point to make because it just
doesn't come up in practice. In the decade or more that I've been
using Visual Studio and automating builds with it, I've *never* needed
to know this and I push beyond the boundaries of what the average
developer does with Visual Studio, in my experience.

Liviu

2010-04-01 03:29:11 UTC

Post by legalize+ (Richard)
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.

This isn't an apples-to-apples comparison then because you've already
spent the time for the startup of the IDE and loading the solution.

It was originally written as a [v6] apples to [v7+] apples comparison.

Post by Liviu
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.

Your feeling is duly noted ;-) Just because you *never* needed it,
doesn't mean that *nobody* ever did or cared.

Liviu

legalize+ (Richard)

2010-04-01 03:56:14 UTC

[Please do not mail me a copy of your followup]

Post by Liviu
Your feeling is duly noted ;-) Just because you *never* needed it,
doesn't mean that *nobody* ever did or cared.

What do you need it for?

Liviu

2010-04-01 05:08:03 UTC

Post by Liviu
Your feeling is duly noted ;-) Just because you *never* needed
it, doesn't mean that *nobody* ever did or cared.

What do you need it for?

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.

Liviu

legalize+ (Richard)

2010-04-01 05:47:30 UTC

[Please do not mail me a copy of your followup]

Post by Liviu
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?

I'm not trying to pick nits, I'm trying to understand why you would
need that. I've converted plenty of projects between different
versions of Visual Studio and never needed to know this.

If you just want to satisfy your curiosity, then you can figure it out
by looking at the command line section which shows the full
command-line and you can observe the differences in the vcproj and the
command-line as you change the GUI choices.

Yes, the mapping of vcproj settings to compiler switches is
undocumented insofar as the file format of a vcproj file is purposely
opaque. If you need to manipulate the settings, you are expected to
use the IDE (manual manipulation) or the automation API (programmatic
manipulation), not edit the text of the vcproj file.

Liviu

2010-04-01 06:43:33 UTC

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.

Post by legalize+ (Richard)
I'm not trying to pick nits, I'm trying to understand why you would
need that. I've converted plenty of projects between different
versions of Visual Studio and never needed to know this.

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.

Post by legalize+ (Richard)
If you just want to satisfy your curiosity, then you can figure it out
by looking at the command line section which shows the full
command-line and you can observe the differences in the vcproj and the
command-line as you change the GUI choices.

This, again, is assuming that you have the full environment installed
for that version, so that you can inspect the vcproj in the IDE (or
rebuild, and look at the build log).

Post by legalize+ (Richard)
Yes, the mapping of vcproj settings to compiler switches is
undocumented insofar as the file format of a vcproj file is purposely
opaque. If you need to manipulate the settings, you are expected to
use the IDE (manual manipulation) or the automation API (programmatic
manipulation), not edit the text of the vcproj file.

That is a _new_ expectation introduced post v6, which is exactly the
point I was making in the original post.

I also find it somewhat ironic that VC's own CRT/ATL/MFC sources
still come with makefiles, not vcproj's.

Liviu

legalize+ (Richard)

2010-04-02 17:48:47 UTC

[Please do not mail me a copy of your followup]

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.

Post by Liviu
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.

Liviu

2010-04-03 18:23:12 UTC

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.

Tim Roberts

2010-04-02 05:25:21 UTC

I would have to disagree also. 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 and over and over and over to change common settings to, for
example, make run-time library settings consistent, or change an include
file path, etc.

**MANY** are the times I've edited the vcproj files by hand. I, too, am
very annoyed that there is no reference to the settings. The situation has
become slightly better now that there are .NET pages that describe the C#
enumerations by name, but they still don't present the numeric values.

--
Tim Roberts, ***@probo.com
Providenza & Boekelheide, Inc.

Pavel A.

2010-04-02 08:15:46 UTC

"Tim Roberts" <***@probo.com> wrote in message news:***@4ax.com...
.......................

Post by Tim Roberts
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 and over and over and over to change common settings to, for
example, make run-time library settings consistent, or change an include
file path, etc.

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

And, have you tried property sheets?
In a property sheet you can define environment variables for external
tools, extra includes, libs and makefile commands.

Regards,
-- pa

Liviu

2010-04-03 18:27:39 UTC

Post by Pavel A.

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

Tim Roberts

2010-04-04 03:47:08 UTC

Post by Pavel A.
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.

Post by Pavel A.
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, ***@probo.com
Providenza & Boekelheide, Inc.

Nobody

2010-03-31 14:40:46 UTC

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.

Giovanni Dicanio

2010-03-31 15:51:19 UTC

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

Stephan T. Lavavej [MSFT]

2010-03-31 21:24:14 UTC

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

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.

Bronek Kozicki

2010-04-03 09:45:41 UTC

Post by verappan
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.

Stephan T. Lavavej [MSFT]

2010-04-05 21:07:09 UTC