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

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

Intellisense isn't (yet) working in C++/CLI code. See
http://herbsutter.wordpress.com/2009...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.

"Howard Swope" <(E-Mail Removed)> wrote in message
news:2E8DB599-E8F1-4B15-917A-(E-Mail Removed)...
> 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

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" <(E-Mail Removed)> wrote in message
news:72D7C065-C484-4753-AFC0-(E-Mail Removed)...
> 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

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]" <(E-Mail Removed)> wrote in message
news:9610034E-DE0B-44D8-B9C5-(E-Mail Removed)...
> Intellisense isn't (yet) working in C++/CLI code. See
> http://herbsutter.wordpress.com/2009...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.
>
> "Howard Swope" <(E-Mail Removed)> wrote in message
> news:2E8DB599-E8F1-4B15-917A-(E-Mail Removed)...
>> 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" <(E-Mail Removed)> wrote in message
news:7C346256-3793-4716-AE9D-(E-Mail Removed)...
> 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.

>
> "Ben Voigt [C++ MVP]" <(E-Mail Removed)> wrote in message
> news:9610034E-DE0B-44D8-B9C5-(E-Mail Removed)...
>> Intellisense isn't (yet) working in C++/CLI code. See
>> http://herbsutter.wordpress.com/2009...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.
>>
>> "Howard Swope" <(E-Mail Removed)> wrote in message
>> news:2E8DB599-E8F1-4B15-917A-(E-Mail Removed)...
>>> 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 wrote:
> 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" <(E-Mail Removed)> wrote in message
news:#(E-Mail Removed)...

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

Alexei Zakharov schrieb:
> "Edward Diener" <(E-Mail Removed)> wrote in message
> news:#(E-Mail Removed)...
>
>> 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.
>

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

--
https://epetitionen.bundestag.de/ind...;petition=4958

Armin Zingler wrote:
> 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).

--
David Wilkinson
Visual C++ MVP