Is There Any Reason to Even Use VC++ Anymore?

[Greg]

Except for legacy or non-.NET applications, is there any reason to use VC++
anymore? It seems that for .NET applications, there would be no reason to
choose C++ over C# since C# is faster to develop with (i.e. no header files,
objects are easier to create and use, C# language is native to .NET)

I'm sure this question will stir some emotions :-)

--
Greg McPherran
www.McPherran.com

[Ted]

Here's some arguments pro-con:

http://blogs.msdn.com/texblog/archiv...21/495404.aspx

Ted.

"Greg" <gm@mcpherran.c om> wrote in message
news:B6******** *************** ***********@mic rosoft.com...

Except for legacy or non-.NET applications, is there any reason to use
VC++
anymore? It seems that for .NET applications, there would be no reason to
choose C++ over C# since C# is faster to develop with (i.e. no header
files,
objects are easier to create and use, C# language is native to .NET)

I'm sure this question will stir some emotions :-)

--
Greg McPherran
www.McPherran.com

[Nishant Sivakumar]

See my article :

[A rational attempt to substantiate C++/CLI as a first class CLI language]
URL http://www.codeproject.com/managedcpp/whycppcli.asp

--
Regards,
Nish [VC++ MVP]
"Greg" <gm@mcpherran.c om> wrote in message
news:B6******** *************** ***********@mic rosoft.com...

Except for legacy or non-.NET applications, is there any reason to use
VC++
anymore? It seems that for .NET applications, there would be no reason to
choose C++ over C# since C# is faster to develop with (i.e. no header
files,
objects are easier to create and use, C# language is native to .NET)

I'm sure this question will stir some emotions :-)

--
Greg McPherran
www.McPherran.com

[Greg]

Thank you both for your responses.

Here's my assessment:

For RAD GUI-intensive front ends that may also be published to web: C#

For Windows-only GUI-intensive apps:
C# unless delivery size is critical (e.g. download) and you don't want to
require cutomer to have .NET then C++ and native only.

For Windows-only apps where the GUI is not the major piece:
If performance and/or delivery size is critical then C++ native. Only use
..NET if it has critical features that are not available in MFC/ATL etc.
We have a spectrum:

-------------------------------------
Web
-------------------------------------
Windows GUI/DB apps
-------------------------------------
Windows number crunch apps
Windows direct graphics games
-------------------------------------
Fast ATL browser objects
-------------------------------------
Driver
-------------------------------------

Each area of the spectrum has languages/technologies that map to it. The
problem is that there are grey areas in between :-) C# is generally advisable
for web and GUI intensive Windows-only apps. C++ native is still generally
advisable for many Windows-only apps. I don't think that just because we have
..NET that MFC and ATL are antiquated. Each has its own place.

C# may begin to drill drown to areas now covered by C++ and C++ may begin to
"drill up" to the web and .NET (as it already has in VS 2005).

I think a smart way to manage all this is to isolate the GUI front end from
your core app crunching in your architecture. This way, the .NET vs native
decision can be made independently for these architectural areas. For
example, one could evolve an app's GUI to .NET and leave the app crunching in
native. Or the same app may even take two forms (no pun intended :-) ) one
with a .NET front end and one with an MFC front end. Both could be supported
with a proper architecture and each flavor could have it's own advantages.
We're not in Kansas anymore Toto :-) Pick your tool for what you're trying
to accomplish and what will get you there fastest. It's not either-or, it's
all of the above :-)

--
Greg McPherran
www.McPherran.com

[Tom Widmer [VC++ MVP]]

Greg wrote:

Except for legacy or non-.NET applications, is there any reason to use VC++
anymore? It seems that for .NET applications, there would be no reason to
choose C++ over C# since C# is faster to develop with (i.e. no header files,
objects are easier to create and use, C# language is native to .NET)

From this, it sounds like you haven't hear of C++/CLI, which is new in
the recently released VC2005.

C++/CLI is also native to .NET, doesn't need header files, and is
(arguably) faster to develop with than C# due to being more fully
featured while still supporting all the convenience of garbage
collection, etc. C++/CLI also produces faster code due to having a
compile-time optimizer (it can generate optimized byte code).

Tom

[David Wilkinson]

Tom Widmer [VC++ MVP] wrote:

Greg wrote:

Except for legacy or non-.NET applications, is there any reason to use
VC++ anymore? It seems that for .NET applications, there would be no
reason to choose C++ over C# since C# is faster to develop with (i.e.
no header files, objects are easier to create and use, C# language is
native to .NET)

From this, it sounds like you haven't hear of C++/CLI, which is new in
the recently released VC2005.

C++/CLI is also native to .NET, doesn't need header files, and is
(arguably) faster to develop with than C# due to being more fully
featured while still supporting all the convenience of garbage
collection, etc. C++/CLI also produces faster code due to having a
compile-time optimizer (it can generate optimized byte code).

Tom

Tom:

Even so, I am concerned about the future of C++ at Microsoft.

If you already know C++ well, the much improved C++/CLI is a natural
choice. But if you do not, then C# must look awful tempting. The
learning curve for C++ was always steep, and CLI certainly has not made
it any easier.

C++/CLI advantages:

1. Deterministic destruction. Nice, but can be done in C# using Dispose
(and maybe C# will get it right one day).

2. Interoperabilit y with native code. Nice, but can also be done less
conveniently from C#. And this feature has a downside - non-verifiable code.

3. Improved optimization. Nice, but not a deal-breaker for most
applications.

4. STL.NET (if we ever see it). This could be a biggie if you want to
write verifiable code, and could constitute the only real advantage over
C# in this situation. But the learning curve of STL is extremely steep,
and many appliactions really do not need it.

5. Traditional C++ portability to other platforms. It remains to be seen
how portable it will remain in the presence of CLI extensions.

C# advantage(s):

A much simpler language, without historical baggage, designed
specifically for the CLR.

I guess I fear that the main function of C++/CLI will be to entice
existing C++ programmers into .NET. When we are all dead, perhaps few
people will be learning it any more. VB.NET, anyone?

David Wilkinson

[Arnaud Debaene]

David Wilkinson wrote:

Tom Widmer [VC++ MVP] wrote:

Greg wrote:

Except for legacy or non-.NET applications, is there any reason to
use VC++ anymore? It seems that for .NET applications, there would
be no reason to choose C++ over C# since C# is faster to develop
with (i.e. no header files, objects are easier to create and use, C#
language
is native to .NET)

From this, it sounds like you haven't hear of C++/CLI, which is new
in the recently released VC2005.

C++/CLI is also native to .NET, doesn't need header files, and is
(arguably) faster to develop with than C# due to being more fully
featured while still supporting all the convenience of garbage
collection, etc. C++/CLI also produces faster code due to having a
compile-time optimizer (it can generate optimized byte code).

Tom

Tom:

Even so, I am concerned about the future of C++ at Microsoft.

Just ask yourself one question : In what language do you think
1) Windows
2 The .NET CLR
are written, and how are they compiled?
If you already know C++ well, the much improved C++/CLI is a natural
choice. But if you do not, then C# must look awful tempting. The
learning curve for C++ was always steep, and CLI certainly has not
made it any easier.

C++/CLI advantages:

1. Deterministic destruction. Nice, but can be done in C# using
Dispose (and maybe C# will get it right one day). The Dispose pattern is far inferior to RAII because resource freeing is on
the responsibility of the client code.

2. Interoperabilit y with native code. Nice, but can also be done less
conveniently from C#. And this feature has a downside -
non-verifiable code. C++ Interop is also much faster and efficient that COM Interop or P/Invoke.
Non-verifiable code is only a matter in low-trusts scenarios : in practice
when writting web code or plugins for some "hosting" apps such as SQL Server
2005.
C# advantage(s):

A much simpler language, without historical baggage, designed
specifically for the CLR.

Agreed, C# is much easier and simplier, but it also lacks some features of
C++ : templates come to mind first (and generics are no replacement for
templates because templates are a Turing-complete language, generics are
not).

Arnaud
MVP - VC

[David Anton]

The main reason to use C++ is that it's still the language you know (even
with the new 2005 syntax). Also, objects are not easier to create in C# and
there are 4 core Microsoft .NET languages: C++, C#, VB, and J#. C# has no
special place in the .NET world - it just happens to be the newest one.

C++ has many language features not available in any other .NET languages.
--
David Anton
www.tangiblesoftwaresolutions.com
Instant C#: VB.NET to C# Converter
Instant VB: C# to VB.NET Converter
Instant C++: C# to C++ Converter
Instant J#: VB.NET to J# Converter

"Greg" wrote:

Except for legacy or non-.NET applications, is there any reason to use VC++
anymore? It seems that for .NET applications, there would be no reason to
choose C++ over C# since C# is faster to develop with (i.e. no header files,
objects are easier to create and use, C# language is native to .NET)

I'm sure this question will stir some emotions :-)

--
Greg McPherran
www.McPherran.com

[Willy Denoyette [MVP]]

See inline

Willy.

"Arnaud Debaene" <ad******@clu b-internet.fr> wrote in message
news:OK******** ******@tk2msftn gp13.phx.gbl...

David Wilkinson wrote:

Tom Widmer [VC++ MVP] wrote:

Greg wrote:

2. Interoperabilit y with native code. Nice, but can also be done less
conveniently from C#. And this feature has a downside -
non-verifiable code.

C++ Interop is also much faster and efficient that COM Interop or
P/Invoke.
Non-verifiable code is only a matter in low-trusts scenarios : in practice
when writting web code or plugins for some "hosting" apps such as SQL
Server 2005.

C++ interop is not faster than PInvoke, whenever you cross the managed
unmanaged border you take a hit, be it using C++ interop or PInvoke. And
whenever you need to pass non blitables to or from managed memory, you take
a hit because of the marshaling that has to be done. Only advantage you have
with C++ interop is that you are in charge (control?) of the marshaling, so
you have a chace to optimize, while using PInvoke, the marshaling is
automatically done for you.

C# advantage(s):

A much simpler language, without historical baggage, designed
specifically for the CLR.

Agreed, C# is much easier and simplier, but it also lacks some features of
C++ : templates come to mind first (and generics are no replacement for
templates because templates are a Turing-complete language, generics are
not).

Arnaud
MVP - VC

[Herby]

We have chosen C++\CLI as our current source code base is in C++ and
provides a clear migration path.
Its also a benefit for us to be able to use mixed mode using both the
un-managed and managed heap in the same application/function.
You could almost think of the syntax extensions almost independent of
..NET. Just can now work with a garbage collector etc.