Sorry... Fat clicked.

Anyway...

My friend was telling me that there is going to be reduced support for C++
/ CLI in VS 2010. Every time I listen to this kind of technology ending
thing, I turns out to be untrue. So I don't know how much stock to put
into it. But C++ / CLI is a fantastic language. It is invaluable to us in
our work. It allows us to expose our underlying DirectX based graphics
engine to people writing C# code. And it allows us to do it elegantly.

My favorite technologies are tools that allow one to move seamlessly at
various levels of complexity. I remember working on an embedded project
where I was writing a device driver that had in-line assembly language
that was embedded in a C++ class that triggered an interrupt routine
written in C. These services were accessed by a .Net compact framework
application and a PC based application, used to program the device, that
was communicating via DCOM. I was able to move seamlessly at the different
levels of complexity and use the right tool for the job. This was
incredibly empowering.

This is the kind of power that C++ /CLI has.

Is the trend to no longer embrace these principals. One can't embed
assembly language in x64 C code, and now I understand C++ / CLI is getting
shorted.

We need to keep all the avenues open

I was talking to a friend and he was telling me of reduced support for
C++ /CLI in VS 2010. Is there an truth to this? I should learn better
than to listen to these type

Since support for C++/CLI from MS has been about NIL, I can't imagine what
you mean by "reduced support".

"Edward Diener" <eddielee_no_spam_here at (no spam) tropicsoft.com> wrote in message
news:#8SLgVcHKHA.4024 at (no spam) TK2MSFTNGP02.phx.gbl...

Since support for C++/CLI from MS has been about NIL, I can't imagine
what you mean by "reduced support".

C++/CLI was once posed as one of the primary languages for .NET
platform. That was the reason for a big push away from "managed C++
extensions", as the managed C++ was limited to interop only (from the
practical point of view). However when the language development almost
completed (which was a tremendous effort) it fell out of favor and now
it's positioned as the interop language again. The "rise and demise" of
C++/CLI was fascinating to watch. It was a fun language, but it didn't
quite make it for various reasons.

Microsoft purposely created that situation in order to promote C#.
They never intended C++/CLI to be on par with C# as a first-class .Net
language, and they lied through their teeth when they originally said
so.
The only reason their C++ customers are still using native code is
because of their abysmal non-support of C++/CLI under .Net.

Microsoft purposely created that situation in order to promote C#.
They never intended C++/CLI to be on par with C# as a first-class .Net
language, and they lied through their teeth when they originally said
so.
The only reason their C++ customers are still using native code is
because of their abysmal non-support of C++/CLI under .Net.

For office-style applications, perhaps. But there are many many problem
domains where having a heavyweight runtime engine doing things outside your
control is unacceptable. Writing native apps in C++ lets you get "close to
the metal". The native C++ compiler is still much much better at
optimization than the .NET runtime. Of course, this only matters for
programs which are CPU-bound, and many aren't (who cares whether processing
a menu click takes .01ms or .20ms ?).

Ben Voigt [C++ MVP] wrote:
Microsoft purposely created that situation in order to promote C#.
They never intended C++/CLI to be on par with C# as a first-class
.Net language, and they lied through their teeth when they
originally said so.
The only reason their C++ customers are still using native code is
because of their abysmal non-support of C++/CLI under .Net.

For office-style applications, perhaps. But there are many many
problem domains where having a heavyweight runtime engine doing
things outside your control is unacceptable. Writing native apps in
C++ lets you get "close to the metal". The native C++ compiler is
still much much better at optimization than the .NET runtime. Of
course, this only matters for programs which are CPU-bound, and many
aren't (who cares whether processing a menu click takes .01ms or
.20ms ?).

I did not mean to claim that there were no uses for native code.

Nonetheless Microsoft's abysmal support for C++/CLI, along with their
almost complete refusal to fix C++/CLI bugs as if doing so would be a
vast concession to C++/CLI programmers rather than a responsibility
which one has when one sells a product, means that C++ programmers are
being herded as quickly as Microsoft hopes to using C# in order to
write .Net modules and applications.

Microsoft sold a lie to C++ programmers wanting to use it for .Net
applications, saying it would be a first class language on par with C#
and VB .Net. Language-wise it is better than C# but support-wise it is
far worse, and therefore largely unusable for the latest .Net
technologies. It's wonderful glue to the native Windows world, and one
can still create components, Windows form derived controls with it, as
well as Windows form and console applications, but that is about it.
For the latest .Net technologies, and ASP .Net, one needs C#, and I
maintain that this was Microsoft's intention from the very start in
order to rope C++ programmers to use C#.

Nonetheless Microsoft's abysmal support for C++/CLI, along with their
almost complete refusal to fix C++/CLI bugs ...

Nonetheless Microsoft's abysmal support for C++/CLI, along with their
almost complete refusal to fix C++/CLI bugs ...

What bugs are you referring to? I've always considered C++/CLI to be
extremely stable.

"Brian Muth" <bmuth at (no spam) mvps.org> wrote in message
news:52AE762D-C744-42F3-AA13-A13C4C2CA790 at (no spam) microsoft.com...
Nonetheless Microsoft's abysmal support for C++/CLI, along with their
almost complete refusal to fix C++/CLI bugs ...

What bugs are you referring to? I've always considered C++/CLI to be
extremely stable.


No answer?

Edward Diener wrote:
Ben Voigt [C++ MVP] wrote:
Microsoft purposely created that situation in order to promote C#.
They never intended C++/CLI to be on par with C# as a first-class
.Net language, and they lied through their teeth when they
originally said so.
The only reason their C++ customers are still using native code is
because of their abysmal non-support of C++/CLI under .Net.
For office-style applications, perhaps. But there are many many
problem domains where having a heavyweight runtime engine doing
things outside your control is unacceptable. Writing native apps in
C++ lets you get "close to the metal". The native C++ compiler is
still much much better at optimization than the .NET runtime. Of
course, this only matters for programs which are CPU-bound, and many
aren't (who cares whether processing a menu click takes .01ms or
.20ms ?).
I did not mean to claim that there were no uses for native code.

Nonetheless Microsoft's abysmal support for C++/CLI, along with their
almost complete refusal to fix C++/CLI bugs as if doing so would be a
vast concession to C++/CLI programmers rather than a responsibility
which one has when one sells a product, means that C++ programmers are
being herded as quickly as Microsoft hopes to using C# in order to
write .Net modules and applications.

Microsoft sold a lie to C++ programmers wanting to use it for .Net
applications, saying it would be a first class language on par with C#
and VB .Net. Language-wise it is better than C# but support-wise it is
far worse, and therefore largely unusable for the latest .Net
technologies. It's wonderful glue to the native Windows world, and one
can still create components, Windows form derived controls with it, as
well as Windows form and console applications, but that is about it.
For the latest .Net technologies, and ASP .Net, one needs C#, and I
maintain that this was Microsoft's intention from the very start in
order to rope C++ programmers to use C#.

Well, you can use all these technologies from C++/CLI. Just not
code-mixed-with-the-markup.

XAML isn't supported in the C++/CLI compiler,
but you can call WPF APIs.

Same with ASP.NET -- You can't embed C++/CLI
code in your ASP pages, but you can build IIS components in C++/CLI.

Historically third-parties have been much better at providing wizards for
C++ than Microsoft, so it's not really a big loss.

Nonetheless Microsoft's abysmal support for C++/CLI, along with their
almost complete refusal to fix C++/CLI bugs ...

What bugs are you referring to? I've always considered C++/CLI to be
extremely stable.

"Brian Muth" <bmuth at (no spam) mvps.org> wrote in message
news:8AD0B70F-EFDB-4F5E-A0D7-D0CC49EA92C5 at (no spam) microsoft.com...


"Brian Muth" <bmuth at (no spam) mvps.org> wrote in message
news:52AE762D-C744-42F3-AA13-A13C4C2CA790 at (no spam) microsoft.com...
Nonetheless Microsoft's abysmal support for C++/CLI, along with
their almost complete refusal to fix C++/CLI bugs ...

What bugs are you referring to? I've always considered C++/CLI to be
extremely stable.


No answer?

There are plenty of bugs in the compiler causing it to fail with
perfectly good source code. That doesn't make the resulting object code
any more or less stable when the compilation phase finishes though.

For example:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=332779

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=473352

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=239629