Rumors of reduced support for C++ /CLI

[Howard Swope]

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

 

[Howard Swope]

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

 

[Ben Voigt [C++ MVP]]

Intellisense isn't (yet) working in C++/CLI code. See
http://herbsutter.wordpress.com/2009/05/20/vs2010-beta-1-now-available/

C++/CLI is still fully supported in the compiler, just some of the IDE has
to make tradeoffs between C++0x which is well-supported in third-party code,
and C++/CLI which is well-supported in existing Visual Studio code. Sutter
says the decision was made to license third-party code (EDG front-end) for
the Intellisense parser and C++/CLI is still a work-in-progress for Edison.

 

[Ben Voigt [C++ MVP]]

AFAIK C++/CLI has never been usable with compact framework, even with
/clrure. So what did you do for NET.CF? Was that the DCOM you mentioned?

 

[Howard Swope]

That's what I get for taking things out of context...

After looking at the discussion, it makes more sense. Perhaps I am a little
defensive. I hate to see the this language take a back seat in tool support.
However, given the managed / unmanaged nature of it, it makes sense that
tools would be a little slower to evolve.

 

[Ben Voigt [C++ MVP]]

That's what I get for taking things out of context...

After looking at the discussion, it makes more sense. Perhaps I am a
little defensive. I hate to see the this language take a back seat in tool
support. However, given the managed / unmanaged nature of it, it makes
sense that tools would be a little slower to evolve.

It makes sense, once we accept that even a megacorporation like Microsoft
can't dedicate unlimited resources. So it's important that they hear from
us about what's most important, so the resources get allocated to the right
places.

 

[Edward Diener]

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

 

[Alexei Zakharov]

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.

 

[Armin Zingler]

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.

It's a pity because it's the only way to build a bridge between the old
and new (managed) world. That's why I think that it is so important. Or
is there an alternative? (for example to write managed wrappers)


Armin

 

[David Wilkinson]

It's a pity because it's the only way to build a bridge between the old
and new (managed) world. That's why I think that it is so important. Or
is there an alternative? (for example to write managed wrappers)

Well, yes, writing managed wrappers using C++ interop is what C++/CLI *is* good
for. A much more pleasant experience than doing it in the old MC++.

Microsoft has not given up on C++/CLI. They have just given up on making it a
first class language for .NET GUI development. Maybe if they had gotten the
language right the first time, things would have been different, but now it
seems a lost cause. Microsoft has decided that most of their C++ customer base
is still using native code, and that is where they are going to put the effort
(after many years of neglect).

 

[Edward Diener]

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.

The only reasons it did not make it is because Microsoft was determined
to tank it from the very beginning in facor of C#. It does not take a
genius to figure that out.

Thus we go the infamous loader lock bug for .Net 1.0/1.1 and the refusal
,starting with ASP .NET and going on now to wpf, wcf, wwf etc. and all
the new .Net technologies centered around C#, to put it on par with C#
as far as technology support.

 

[Edward Diener]

Well, yes, writing managed wrappers using C++ interop is what C++/CLI
*is* good for. A much more pleasant experience than doing it in the old
MC++.

It's a much better language than C#, but C# is MS's baby so they are not
going to support C++/CLI for key .Net technologies ( ASP .NET, wpf, wwf,
wcf etc. ).

Microsoft has not given up on C++/CLI. They have just given up on making
it a first class language for .NET GUI development. Maybe if they had
gotten the language right the first time, things would have been
different, but now it seems a lost cause. Microsoft has decided that
most of their C++ customer base is still using native code, and that is
where they are going to put the effort (after many years of neglect).

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.

 

[Ben Voigt [C++ MVP]]

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

 

[Edward Diener]

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

 

[Ben Voigt [C++ MVP]]

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.

 

[Brian Muth]

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]

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

No answer?

 

[Ben Voigt [C++ MVP]]

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

 

[Edward Diener]

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

Here are bug report numbers:

101670
101671
101674
101677
101678
192619
199186
205446
216882
249881
275035
295385
344776
362782
431084

What is most amusing is that you equate C++/CLI stability as an
indicator of good support. I, OTOH, consider good support the ability to
implement features and to fix bugs.

Clearly MS's decision not to support the latest .Net technologies for
C++/CLI in VS's visual environment, and their equally fatuous insistence
that real C++/CLI bugs being reported to them should not be fixed
because it they do not meet the "triage requirements", which is just MS
speak for "we don't want to fix them" and nothing more, indicates to me
abysmal support for C++/CLI.

 

[Edward Diener]

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

See my list in this thread and I am sure there are plenty more also.

For MS the bug never meets the "triage requirements" to fix it. Of
course that terminology is just invented MS speak for "we don't feel
like fixing the bug" and nothing more.