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

[Guest]

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

 

[Ted]

Here's some arguments pro-con:

http://blogs.msdn.com/texblog/archive/2005/11/21/495404.aspx

Ted.

 

[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

 

[Guest]

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

 

[Tom Widmer [VC++ MVP]]

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]

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

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

 

[Guest]

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

 

[Willy Denoyette [MVP]]

See inline

Willy.

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.

 

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

 

[Peter Oliphant]

I've heard VS C++.NET can run from 6-10 times FASTER than VS C#.NET. That's
a pretty good selling point right there... : )

[==P==]

 

[Willy Denoyette [MVP]]

Sure, for those who believe this nonsense. Those who ran some benchmarks
know that there is almost no difference, for some specific cases C++/CLI is
a bit faster and in other cases C# is a bit faster. This is quite normal if
you know that both front-end compilers emit MSIL and the bulk of the
optimizations are done at JIT compile time. Sure the C++ compiler can spend
some extra time to optimize MSIL, while the C# compiler is more time
constrained, but in reality there is very little that can be done at the
MSIL level. Note also that a great deal of the code that gets executed in a
real world application comes from the FCL which is written in C#.
Believe me, performance is not C++/CLI's selling point.

Willy.

I've heard VS C++.NET can run from 6-10 times FASTER than VS C#.NET.
That's a pretty good selling point right there... : )

[==P==]

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.

 

[Peter Oliphant]

I never did any benchmarks, so I was basing my statement on other reports.
Thus I believe your findings more than what I've read (even though,
ironically, all I've done is read what you've said in saying this...lol). So
speed is not a selling point.

Still, I prefer to use C++ over C#, probably just because I prefer (am more
familiar with) the syntax. And, I'm afraid of seeing this pop up one day on
the MS website:

"MS has deprecated C++ in favor of C#". <shiver>

[==P==]

Sure, for those who believe this nonsense. Those who ran some benchmarks
know that there is almost no difference, for some specific cases C++/CLI
is a bit faster and in other cases C# is a bit faster. This is quite
normal if you know that both front-end compilers emit MSIL and the bulk of
the optimizations are done at JIT compile time. Sure the C++ compiler can
spend some extra time to optimize MSIL, while the C# compiler is more time
constrained, but in reality there is very little that can be done at the
MSIL level. Note also that a great deal of the code that gets executed in
a real world application comes from the FCL which is written in C#.
Believe me, performance is not C++/CLI's selling point.

Willy.

I've heard VS C++.NET can run from 6-10 times FASTER than VS C#.NET.
That's a pretty good selling point right there... : )

[==P==]

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.

 

[Willy Denoyette [MVP]]

I never did any benchmarks, so I was basing my statement on other reports.
Thus I believe your findings more than what I've read (even though,
ironically, all I've done is read what you've said in saying this...lol).
So speed is not a selling point.

Still, I prefer to use C++ over C#, probably just because I prefer (am
more familiar with) the syntax. And, I'm afraid of seeing this pop up one
day on the MS website:

"MS has deprecated C++ in favor of C#". <shiver>

C++ != C++/CLI remember!
What's possible is that you may see "MS has deprecated C++/CLI in favor of
C#", but they would never deprecate the language (native C++) they use to
build >95% of their products.


Willy.

 

[Peter Oliphant]

Here's what I'm getting at. I use to program in C++ before managed stuff
came into play (gc). So, when managed stuff did come into play, I had to
convert my stuff to it. Then CLI came into play. Now I'm converting my stuff
to CLI since gc has been deprecated.

Short of only using 'vanilla' C++, can I ever write code I'm sure will still
be valid 'forever'? That is, code that can be re-used in future projects,
say, 2+ years from now? How can one build a library of tools if the syntax
keeps changing? Hence, I'm even worried about:

"MS has deprecated C++/CLI in favor of C#". <shiver>

Has CLI been made to be 'here to stay", or can we expect some VS.NET 2007
upgrade to possibly deprecate CLI and expect us to learn yet another new
syntax? Like I've mentioned before, one of the purposes of languages like
C++ is the concept it will be re-usable in the future. This constantly
changing the syntax violates that contract.

IMHO, a new version of a product should always be 100% backwards comaptible
IF it's going to be called an UPGRADE. CLI is not backwards comaptible with
'gc', thus requiring conversion time that shouldn't be necessary for an
upgrade, but in this case is absolutely required. Hence, VS 2005 is not an
upgrade to 2003, IMHO, but a 'new' language.

That being said, I really enjoy this new syntax, but wish I hadn't learned
and programmed using "gc" syntax so much. And having done that, I'm worried
a bit about investing time in CLI, since it could be deprecated in a few
years too.

Do we have ANY guarantee along these lines, even in terms of limited-time
(i.e., MS warrants that CLI will NOT be deprecated for X number of years)?

[==P==]

 

[Bo Persson]

Here's what I'm getting at. I use to program in C++ before managed
stuff came into play (gc). So, when managed stuff did come into
play, I had to convert my stuff to it. Then CLI came into play. Now
I'm converting my stuff to CLI since gc has been deprecated.

Short of only using 'vanilla' C++, can I ever write code I'm sure
will still be valid 'forever'? That is, code that can be re-used in
future projects, say, 2+ years from now? How can one build a library
of tools if the syntax keeps changing? Hence, I'm even worried
about:

"MS has deprecated C++/CLI in favor of C#". <shiver>

Has CLI been made to be 'here to stay", or can we expect some VS.NET
2007 upgrade to possibly deprecate CLI and expect us to learn yet
another new syntax? Like I've mentioned before, one of the purposes
of languages like C++ is the concept it will be re-usable in the
future. This constantly changing the syntax violates that contract.

IMHO, a new version of a product should always be 100% backwards
comaptible IF it's going to be called an UPGRADE. CLI is not
backwards comaptible with 'gc', thus requiring conversion time that
shouldn't be necessary for an upgrade, but in this case is
absolutely required. Hence, VS 2005 is not an upgrade to 2003, IMHO,
but a 'new' language.

That being said, I really enjoy this new syntax, but wish I hadn't
learned and programmed using "gc" syntax so much. And having done
that, I'm worried a bit about investing time in CLI, since it could
be deprecated in a few years too.

Do we have ANY guarantee along these lines, even in terms of
limited-time (i.e., MS warrants that CLI will NOT be deprecated for
X number of years)?

Noooo!

You will never, ever get any guarantees at all.

I was around when MS introduced Windows 1.0. Several years ago...

At the time, the promise was "learn this new Windows API, and you will
never have to learn another interface again".

Yeah, right!


Bo Persson

 

[Brian Muth]

Here's what I'm getting at. I use to program in C++ before managed stuff
came into play (gc). So, when managed stuff did come into play, I had to
convert my stuff to it.

Why? Is someone holding a gun to your head?

In our development environment, we start from the premise that "what isn't
broken shouldn't be fixed". Perhaps there was a compelling reason on your
case, but I wouldn't be seduced into "upgrading" your source code simply
because the features become available.

Then CLI came into play. Now I'm converting my stuff to CLI since gc has
been deprecated.

Short of only using 'vanilla' C++, can I ever write code I'm sure will
still be valid 'forever'? That is, code that can be re-used in future
projects, say, 2+ years from now? How can one build a library of tools if
the syntax keeps changing? Hence, I'm even worried about:

"MS has deprecated C++/CLI in favor of C#". <shiver>

C++/CLI offers capabilities and a blending of the managed and native worlds
that cannot be duplicated with C#. I can assure you it is here for the long
term.

Has CLI been made to be 'here to stay", or can we expect some VS.NET 2007
upgrade to possibly deprecate CLI and expect us to learn yet another new
syntax? Like I've mentioned before, one of the purposes of languages like
C++ is the concept it will be re-usable in the future. This constantly
changing the syntax violates that contract.

I disagree. Language extensions are never a contract, and that is exactly
what the old syntax represented. The old syntax is still supported, so you
have lots of time to adapt to the new "language extensions". Obviously, it
is not in the vendor's interest to keep modifying the language extensions
with each new version. But in this case, the syntax has been cleaned up, and
there is a clearer distinction between native pointers and reference
pointers.

IMHO, a new version of a product should always be 100% backwards
comaptible

Egad.... then I daresay you haven't had much experience putting out a
product that is widely used. There is a natural conflict between maintaining
backwards-compatibility and jettisoning out-dated and dangerous features and
coding styles. The former doesn't always win.

Indeed, even your favourite language C doesn't support the early versions of
the language when it was first developed by Bell Labs. Remember when int's
and pointers could be used pretty much interchangeably? Do you really want
to continue to support that?

IF it's going to be called an UPGRADE. CLI is not backwards comaptible
with 'gc', thus requiring conversion time that shouldn't be necessary for
an upgrade, but in this case is absolutely required. Hence, VS 2005 is not
an upgrade to 2003, IMHO, but a 'new' language.

That being said, I really enjoy this new syntax, but wish I hadn't learned
and programmed using "gc" syntax so much.

I think that is the real burn you are feeling. I managed to skip the "gc"
syntax... it was ugly, and Microsoft indicated this was going to be
revamped.

And having done that, I'm worried a bit about investing time in CLI, since
it could be deprecated in a few years too.

Again, don't worry. This is going to be around for the long term. Expect
improvements, bug fixes, and so on, but nothing as drastic as the recent
"upgrade".

Do we have ANY guarantee along these lines, even in terms of limited-time
(i.e., MS warrants that CLI will NOT be deprecated for X number of years)?

I wouldn't expect a guarantee from Microsoft. But they do listen to their
developers, and they do read this newsgroup, so your posting will be noted.

Brian (and I don't represent Microsoft

 

[Peter Oliphant]

Why? Is someone holding a gun to your head?

This is how it went. I was using 2003 just fine. 2005 comes out, so our
company upgrades. We want the newest stuff because UPGRADES typically fix
any old problems and bugs.

I then took the 'old' source and decided to now use 2005. What's this? It
wants to convert my 2003 source to 2005 format, and tells me there is no way
to reverse? Ok, that's fine, no problem. Then, guess what? It doesn't
compile because its not backwards compatible...

Yes, I still have backups of the 2003 version, and I could use them. BUT -
MS has announced that 'gc' has been deprecated. So, if I continue to use
2003 MS has aggresively announced they won't support my code in the near
future...

So, YES, there IS a gun being held to my head in this matter... : )

The old syntax is still supported...

.... but has been deprecated by MS, and 'deprecated' mean 'will not be
supported in the near future'. So if I choose not to learn the syntax of
2005 MS says I'm on my own...

Egad.... then I daresay you haven't had much experience putting out a
product that is widely used. There is a natural conflict between
maintaining

Yeah, only 20+ published computer games, some of which have sold
platinum...lol I've been designing and programming now for 36 years. One
of my computer game projects took 5 years (that should have taken 2 years)
because CPU's kept upgrading:

286 -> 386 -> 486 -> Pentium

Now this can happen becuase languages change. That's not good...

Didn't MS say this about 'gc' syntax too? : )

[==P==]

PS - Like I said, I do love the new syntax, but I now have at least three
different syntax's running around in my head and like 50,000 lines of
library tool code that has seen all three versions. Had they just skipped
'gc' and gone directly to 'CLI' I'd have been mch happier. But hey, I like
product testing (and paying $1000's for the privilege for upgrades) so MS
can get it right... LOL

Seriously, I do think MS is doing a good job here with CLI and the way all
of the languages (VB, C++, J#, and C#) use a common basis. Just they could
have been more forthcoming about how 2003 won't compile under 2005 without
changes...

 

[Brian Muth]

Yes, I still have backups of the 2003 version, and I could use them. BUT -
MS has announced that 'gc' has been deprecated. So, if I continue to use
2003 MS has aggresively announced they won't support my code in the near
future...

Can you support this statement with a link?

So, YES, there IS a gun being held to my head in this matter... : )


... but has been deprecated by MS, and 'deprecated' mean 'will not be
supported in the near future'.

Nonsense.

RDS has been deprecated for 6 years. Yet it is still present in Microsoft
Windows 2003 Server and therefore it is still supported.

"Deprecated" does not mean "it will be not supported in the near future". It
does mean that there is no further R&D in this area. It is a strong hint
that new code should adopt the recommended replacement technology. But it
shouldn't make you panic and start tearing up your old code. In the case of
RDS, the software is sealed, so it means there will be no changes to the
software in future releases. But RDS is still around today. And I'll bet RDS
is going to appear in Windows Vista, identical to the code present in
Windows 2003 Server.

[==P==]

PS - Like I said, I do love the new syntax, but I now have at least three
different syntax's running around in my head and like 50,000 lines of
library tool code that has seen all three versions. Had they just skipped
'gc' and gone directly to 'CLI' I'd have been mch happier.

Agree whole-heartedly.

Seriously, I do think MS is doing a good job here with CLI and the way all
of the languages (VB, C++, J#, and C#) use a common basis. Just they could
have been more forthcoming about how 2003 won't compile under 2005 without
changes...

I have to admit I don't feel the same compulsion to recompile my code under
the latest compiler. I have lots of code that compiles just fine under VC
6.0, and I really don't care if MS stops supporting this version of the
compiler one day. My code will still compile without their support.

 

[Peter Oliphant]

MS has announced that 'gc' has been deprecated....

Can you support this statement with a link?

Sure:

http://msdn2.microsoft.com/en-us/library/xey702bw(en-us,VS.80).aspx

Quote on this page ("This syntax" refers to C++/CLI syntax):

"This syntax replaces the previous syntax, known as Managed Extensions for
C++. Managed Extensions for C++ syntax is are still available, but as a
deprecated feature under /clrldSyntax compiler option."

[==P==]

Yes, I still have backups of the 2003 version, and I could use them.
BUT - MS has announced that 'gc' has been deprecated. So, if I continue
to use 2003 MS has aggresively announced they won't support my code in
the near future...

Can you support this statement with a link?

So, YES, there IS a gun being held to my head in this matter... : )


... but has been deprecated by MS, and 'deprecated' mean 'will not be
supported in the near future'.

Nonsense.

RDS has been deprecated for 6 years. Yet it is still present in Microsoft
Windows 2003 Server and therefore it is still supported.

"Deprecated" does not mean "it will be not supported in the near future".
It does mean that there is no further R&D in this area. It is a strong
hint that new code should adopt the recommended replacement technology.
But it shouldn't make you panic and start tearing up your old code. In the
case of RDS, the software is sealed, so it means there will be no changes
to the software in future releases. But RDS is still around today. And
I'll bet RDS is going to appear in Windows Vista, identical to the code
present in Windows 2003 Server.

[==P==]

PS - Like I said, I do love the new syntax, but I now have at least three
different syntax's running around in my head and like 50,000 lines of
library tool code that has seen all three versions. Had they just skipped
'gc' and gone directly to 'CLI' I'd have been mch happier.

Agree whole-heartedly.

Seriously, I do think MS is doing a good job here with CLI and the way
all of the languages (VB, C++, J#, and C#) use a common basis. Just they
could have been more forthcoming about how 2003 won't compile under 2005
without changes...

I have to admit I don't feel the same compulsion to recompile my code
under the latest compiler. I have lots of code that compiles just fine
under VC 6.0, and I really don't care if MS stops supporting this version
of the compiler one day. My code will still compile without their support.