C++/CLI Death 2008, 2009 or 2010?

[Eduardo Sobrino]

Recent review of PDC-2008 while searching for any improvement / enhancement
of C++/CLI and/or future directions was a disappointment. While searching
the issue on the net I came across of a few similar claims in general.
The main claim from MS was that "We have been hearing what customers tell us
and invested our time in that..." or some similar statement. So, what this
means to people like me that has invested quite some time and resources in
C++/CLI development? After being bombarded with C++/CLI negative news I
won’t even talk about how great we have done with it.
I will offer you just one reference
http://www.tech-archive.net/Archive...lic.dotnet.languages.vc/2007-12/msg00254.html
Just look up for the “VS 2008 C++/CLI Enhancements†subject and you will
find that many of the first 20 hits related to disappointed people.
State the Date and/or Year of the "C++/CLI Death 2008, 2009 or 2010?" or
does it already happened.
Any inside on the subject is greatly appreciated. At this point I am
strongly disappointed about Microsoft lack of commitment to provide the same
support for all .Net Language.

 

[Jeroen Mostert]

Recent review of PDC-2008 while searching for any improvement / enhancement
of C++/CLI and/or future directions was a disappointment. While searching
the issue on the net I came across of a few similar claims in general.
The main claim from MS was that "We have been hearing what customers tell us
and invested our time in that..." or some similar statement. So, what this
means to people like me that has invested quite some time and resources in
C++/CLI development?

I've heard this argument before and frankly, I don't really see what the
fuss is. What are you *expecting* out of C++/CLI development? The thing
C++/CLI excels at is interop scenarios, gluing managed and unmanaged
together. I'm not saying there's no room for improvement in that area, but
it'll surely be limited. For Good Old Win32 development, just stick to C++
(you know, the language that has more than one compiler for it). For a
purely managed experience in a C-like language, C#'s your uncle.

I've heard similar jeremiads from the VB.NET people whenever C# got even a
single feature they didn't have (VB.NET has stuff C# doesn't have, like
wicked XML support and the amazingly time-saving My hierarchy, but far fewer
people seem to complain about that). Apparently nobody appreciates that the
..NET languages, while all equal to the CLR, are not all equal in feature
sets and flavor; instead, everyone wants everything the other guys have. Or
at least everything C# has.

The C++/CLI developer base that wants this is probably not big enough to get
the same treatment -- as simple matter of economy, not a deliberate snub.
Don't underestimate the time and resources needed for new development --
it's not like they can simply "port a few features" they already developed
in other languages. If everything they thought up had to be integrated
perfectly in all the .NET languages Microsoft ships, they'd probably think
twice before developing anything new.

To me, the whole thing smacks a bit of language bigotism. If you want what's
in C#/VB.NET/F#/whatever, why don't you just use that language? OK, so I
could accept the argument that if you're a C++ nut, something like VB.NET
wouldn't be your thing, but the same cannot apply to C# -- that's very easy
to pick up if you know C++. Arguments like "but without templates/multiple
inheritance/protected abstract virtual base pure virtual private
destructors, I simply cannot think/good code is simply impossible/it's too
cumbersome to even bother with" are a definite sign of language bigotism.

And it's not like you have to throw away your existing code -- the great
thing about the CLR is that all classes can live in harmony, regardless of
what language they were written in. Write your propellerhead unmanaged
interop code in C++/CLI, stick it in an assembly and use it from C#. Or
write your shiny new feature-laden code in C#, stick it in an assembly and
use it from C++/CLI. Use ILMerge if you can't live with having multiple
assemblies.

Any inside on the subject is greatly appreciated.

I'm not an insider, obviously, just contributing $0.02.

 

[Eduardo Sobrino]

The IJW and related Unmanaged to Manage is definitively great benefit and I
will not do it another way since it is cleaner than the same effort in
whatever other Language.

We do write tons of VB.Net and C# mainly for UI, ASP.Net and/or whenever
there is a task that it's development is simpler on any of those and/or as
Customer mandates. Still if we can and knowing how simpler and clear (to us)
to do the job in C++/CLI we just do it. We do most of the none-related UI
code in C++/CLI and our experience is great.

The argument of "you only want to write in X language" don't apply to us
since we don't care in want language the customer wants its code to be
written in. Still, if we can select we will write any code in whatever is
simpler and cleaner to get the job done.

Let's say:

property String ^CustomerName; // C++/CLI that's it...

------------------------------------------------- Or In VB.Net

Private m_CustomerName AS String
Public Property CustomerName AS String
Get
Return m_CustomerName
End Get
Set (ByVal value As String)
m_CustomerName
End Set
End Property

------------------------------------------------- Or In C#

private String m_CustomerName;
public String CustomerName
{
get { return m_CustomerName; }
set { m_CustomerName = value; }
}

And how about "Deterministic Finalizaton" ...

void MyFunc(...)
{
AnyClass myLocalVar; // C++/CLI
}

And as many know crossing over (to unmanaged code) is another story where
for us there is no way to beat the simplicity of doing it in C++/CLI with the
IJW capability. Getting the same level of clarity from other languages is
not even close, to review just a few scenarios...

I understand that there are a lot of developers that moving to another
language and having the same productivity, control and understanding is to
much of an effort and they stick to C# and/or VB.Net and that is fine and
great with me, still I like to have the option of also using C++/CLI being
sure that it will be supported in future releases and better if it gets the
same treatment, improvements and access to the same functionality as the
other laguages as it should be; don't you think?

Again, we move to any .Net Language without any complain and be equally
happy and productive... Still it will be a lot better if the developer can
chose the best language for a particular task without any limitation imposed
by it's development and / or lack of support...

What is the C++/CLI future if any?

This I will like to know...

Jeroen comments are appreciated...

 

[Jeroen Mostert]

Let's say:

property String ^CustomerName; // C++/CLI that's it...

------------------------------------------------- Or In VB.Net

Private m_CustomerName AS String
Public Property CustomerName AS String
Get
Return m_CustomerName
End Get
Set (ByVal value As String)
m_CustomerName
End Set
End Property

------------------------------------------------- Or In C#

private String m_CustomerName;
public String CustomerName
{
get { return m_CustomerName; }
set { m_CustomerName = value; }
}

C# 3:

public string CustomerName { get; set; }

Good ideas are worth stealing, after all.

And how about "Deterministic Finalizaton" ...

void MyFunc(...)
{
AnyClass myLocalVar; // C++/CLI
}

using (myLocalVar) {
...
}

But the issue of DF versus garbage collection is much bigger than the
languages (crossing over into philosophy, really) so I wouldn't call the
fact that C++/CLI has to support it both a feature per se.

And as many know crossing over (to unmanaged code) is another story where
for us there is no way to beat the simplicity of doing it in C++/CLI with the
IJW capability. Getting the same level of clarity from other languages is
not even close, to review just a few scenarios...

Exactly, that's more or less what C++/CLI was born to do. You can trivially
supply unmanaged code with a managed wrapper and bring your code to the
managed world -- or the other way around, of course.

I understand that there are a lot of developers that moving to another
language and having the same productivity, control and understanding is to
much of an effort and they stick to C# and/or VB.Net and that is fine and
great with me, still I like to have the option of also using C++/CLI being
sure that it will be supported in future releases and better if it gets the
same treatment, improvements and access to the same functionality as the
other laguages as it should be; don't you think?

Sure, but I don't understand how you got the impression that C++/CLI is
"dead" or "dying" anyway. It's going to go soon because Microsoft isn't
constantly releasing new features for it? The new C standard was 10 years in
the making, C++ moves at a glacial pace at well -- are those languages going
away soon?

C++/CLI doesn't need WPF, LINQ, ASP.NET etc. to stay viable. It's occupying
a niche (seamless interop) that can't be occupied by any other language.

Again, we move to any .Net Language without any complain and be equally
happy and productive... Still it will be a lot better if the developer can
chose the best language for a particular task without any limitation imposed
by it's development and / or lack of support...

What is the C++/CLI future if any?

This only Microsoft can answer, but they'd be fools if they didn't at least
continue to support the language as-is for the foreseeable future. It's just
too damn handy for interop scenarios (of which there are going to remain
quite a few in the future -- the MS world won't be "wholly .NET" for years).

 

[PvdG42]

C# 3:

public string CustomerName { get; set; }

Good ideas are worth stealing, after all.

using (myLocalVar) {
...
}

But the issue of DF versus garbage collection is much bigger than the
languages (crossing over into philosophy, really) so I wouldn't call the
fact that C++/CLI has to support it both a feature per se.

Exactly, that's more or less what C++/CLI was born to do. You can
trivially supply unmanaged code with a managed wrapper and bring your code
to the managed world -- or the other way around, of course.

Sure, but I don't understand how you got the impression that C++/CLI is
"dead" or "dying" anyway. It's going to go soon because Microsoft isn't
constantly releasing new features for it? The new C standard was 10 years
in the making, C++ moves at a glacial pace at well -- are those languages
going away soon?

C++/CLI doesn't need WPF, LINQ, ASP.NET etc. to stay viable. It's
occupying a niche (seamless interop) that can't be occupied by any other
language.

This only Microsoft can answer, but they'd be fools if they didn't at
least continue to support the language as-is for the foreseeable future.
It's just too damn handy for interop scenarios (of which there are going
to remain quite a few in the future -- the MS world won't be "wholly .NET"
for years).

First, let me say that I agree with you and appreciate the clear
differentiation. I'll add that I, like the OP have been a bit disappointed
that C++/CLI didn't "get everything", even though I know it's not
economically feasible. I think part of my unrealistic expectations were
driven by several books published (which shall remain nameless to protect
the guilty) that address C++/CLI from a general development prespective,
thus misleading the reader to an extent. So, finally my question: do you
know of any good titles that might be useful in teaching college students to
exploit C++/CLI strengths? Thanks!

 

[Jeroen Mostert]

First, let me say that I agree with you and appreciate the clear
differentiation. I'll add that I, like the OP have been a bit
disappointed that C++/CLI didn't "get everything", even though I know
it's not economically feasible. I think part of my unrealistic
expectations were driven by several books published (which shall remain
nameless to protect the guilty) that address C++/CLI from a general
development prespective, thus misleading the reader to an extent. So,
finally my question: do you know of any good titles that might be useful
in teaching college students to exploit C++/CLI strengths? Thanks!

I don't think college students should be bothering with C++/CLI at all, to
be honest -- unless they want to pick it up themselves, as a hobby. It's a
specialized tool for professional programmers, not a general language you'd
want to expose students to.

If you want to invest in a general purpose language, learn C++ instead, and
look beyond Windows (don't bother with things like MFC if you don't have
to). Moving to C++/CLI from that would be a specialization for those people
who want to use C++ with the .NET framework. If you're more interested in
the .NET framework than in C++, though, learning C# is a much better option
-- it's cleaner conceptually and there's a lot more material.

If you know C++ and C#, moving to C++/CLI should be easy enough that you can
do it with just the reference documentation from Microsoft. Starting with
C++/CLI if you know neither C++ nor C# seems to be a misguided effort to me
-- you'll learn neither clean, portable C++ nor the most effective ways to
leverage the .NET framework.

Contrary to how it might look, C++/CLI is not the language to learn if you
want to know both C++ and the .NET framework, nor is it "the next logical
step" for people who use C++ for Win32 development. C++/CLI has pointers
*and* references *and* managed references *and* deterministic finalization
*and* garbage collection... C++ and .NET should really be studied
separately, so you know what side of the border each C++/CLI feature is on.

Contrary to C++ and C#, I have read no C++/CLI books (keeping in line with
the theme above, I guess), so I can't really make book recommendations. I
would definitely stay away from the books that try to sell it as a C++
upgrade, though, or as a language for general-purpose development. That's
not doing anyone a service.

 

[PvdG42]

I don't think college students should be bothering with C++/CLI at all, to
be honest -- unless they want to pick it up themselves, as a hobby. It's a
specialized tool for professional programmers, not a general language
you'd want to expose students to.

If you want to invest in a general purpose language, learn C++ instead,
and look beyond Windows (don't bother with things like MFC if you don't
have to). Moving to C++/CLI from that would be a specialization for those
people who want to use C++ with the .NET framework. If you're more
interested in the .NET framework than in C++, though, learning C# is a
much better option -- it's cleaner conceptually and there's a lot more
material.

If you know C++ and C#, moving to C++/CLI should be easy enough that you
can do it with just the reference documentation from Microsoft. Starting
with C++/CLI if you know neither C++ nor C# seems to be a misguided effort
to me -- you'll learn neither clean, portable C++ nor the most effective
ways to leverage the .NET framework.

Contrary to how it might look, C++/CLI is not the language to learn if you
want to know both C++ and the .NET framework, nor is it "the next logical
step" for people who use C++ for Win32 development. C++/CLI has pointers
*and* references *and* managed references *and* deterministic finalization
*and* garbage collection... C++ and .NET should really be studied
separately, so you know what side of the border each C++/CLI feature is
on.

Contrary to C++ and C#, I have read no C++/CLI books (keeping in line with
the theme above, I guess), so I can't really make book recommendations. I
would definitely stay away from the books that try to sell it as a C++
upgrade, though, or as a language for general-purpose development. That's
not doing anyone a service.

I very much appreciate you taking the time to share your views. Actually, we
have a second C++ class that addresses Windows app development and I have
already started the process of converting it to a more generalized second
C++ course that simply ignores CLI. For Windows and web stuff, a second
course in C# would be far better.

Thanks again for taking the time to respond in detail.

 

[Ben Voigt [C++ MVP]]

First, let me say that I agree with you and appreciate the clear

differentiation. I'll add that I, like the OP have been a bit disappointed
that C++/CLI didn't "get everything", even though I know it's not
economically feasible. I think part of my unrealistic expectations were

Or perhaps the compatibility with standard C++ is valued more by most of the
users than new and incompatible extensions would be? Based on hearing a lot
of complaints about Microsoft's "embrace + extend" policies in other
languages (MS version of Java, MS version of HTML, MS version of DHTML, MS
version of JavaScript) I think that this is far more important than the
syntactic sugar of, e.g. LINQ. Especially as standard C++ may offer
something similar in the future (C++0x adds support for custom literals,
lambdas, closures, for example), definitely I, and I believe most of the
other C++/CLI users, would rather the C++/CLI implementation be compatible
with standard C++ than C#.

So maybe making it a little easier to mix C++/CLI and C# code in the same
project would have a lot bigger payoff than implementing XAML and LINQ in
C++/CLI.

 

[RFOG]

Hello all.

I've not followed this thread, but after been watched the CTP I asked for
clarification to Visual Studio Team and I got the next response:

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=382151

Recent review of PDC-2008 while searching for any improvement /
enhancement
of C++/CLI and/or future directions was a disappointment. While
searching
the issue on the net I came across of a few similar claims in general.
The main claim from MS was that "We have been hearing what customers
tell us
and invested our time in that..." or some similar statement. So, what
this
means to people like me that has invested quite some time and resources
in
C++/CLI development? After being bombarded with C++/CLI negative news I
won’t even talk about how great we have done with it.
I will offer you just one reference,
http://www.tech-archive.net/Archive...lic.dotnet.languages.vc/2007-12/msg00254.html
Just look up for the “VS 2008 C++/CLI Enhancements†subject and you will
find that many of the first 20 hits related to disappointed people.
State the Date and/or Year of the "C++/CLI Death 2008, 2009 or 2010?" or
does it already happened.
Any inside on the subject is greatly appreciated. At this point I am
strongly disappointed about Microsoft lack of commitment to provide the
same
support for all .Net Language.

--
Microsoft Visual C++ MVP
========================
Mi blog sobre programación: http://geeks.ms/blogs/rfog
Momentos Leves: http://momentosleves.blogspot.com/
Cosas mías: http://rfog.blogsome.com/
Libros, ciencia ficción y programación
========================================
El autor es el que menos cobra... De la edición de mi novela Corazón tan
blanco, por la que el lector paga ocho dolares, yo me llevo sólo 40
centavos.
-- Javier Marías. (1951) Escritor español.

 

[PvdG42]

Hello all.

I've not followed this thread, but after been watched the CTP I asked for
clarification to Visual Studio Team and I got the next response:

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=382151

Thanks for posting the link. Looks like all the negative "suspicions" have
come true. Logical, inevitable, but disappointing to some of us.
Off to learn more C# and develop a second C# course to replace the course
that includes CLI content...

 

[Mark Salsbery [MVP]]

THAT would be really cool IMO!

Mark

 

[Ben Voigt [C++ MVP]]

I'm not sure if it has been publicly stated by Microsoft, but the message
is clear: C++/CLI is for the interop only. At the beginning it was
intended to be a first class language for .NET, but since then there's
been a change of plans. There will be no new development and no more
(minimal) investment in C++/CLI. In fact Microsoft is cutting features as
you have noticed to minimize support cost.

This last claim is total nonsense. There is plenty of new development and
investment in C++/CLI at Microsoft. But the new features are coming from
C++0x, not C# (which is as it should be for a language for C++ in the name).

I think you are mistaking the forms designer for the language. No features
have been cut from the language since its introduction in VS2005 as far as I
can tell, and I'd be interested to know what you think has been cut.