Disappointment in VC++ .Net in VS2008

[Edward Diener]

I think you are getting a little conspiratorial. Microsoft does not have a
single mind. It is a large organisation with lots of brilliant people and
there is a lot of internal politics. There are people who love C++ and its
extensions and people who think C# is the future. The relative strength of
the different forces waxes and wanes.


I'm sure there is truth in this. But there is another truth that your
account omits. There is a strong economic motive in making programming
easier. Top notch programmers are hard to find, expensive to hire, and their
time (along with that of anyone being paid) is valuable. Accordingly, there
is a strong incentive to offer programming languages that are easy to learn
and use. C# is a language for the masses. C++ is less so.

You see the same thing in the OS and application space --- a tendency to
"simplify" the way the software works in order to make it "user friendly",
much to the irritation of power users. But, annoying though this is, MS
probably knows what it is doing from an economic point of view.


Not for you. For most programmers, it probably is.

I do not really care that much what the differences between C++ and C#
are. I only care that Microsoft, and the likes of Lippman and Sutter,
went out of their way to tout C++/CLI as a programming language for .Net
for C++ programmers, only to drop it like a hot potato when they decided
that C# would be the way to go for all of the key .Net technologies.

They wasted my time and my efforts and I am sure they did so for many
C++ programmers. My OP is a reflection of that reality.

I can very adequately program using C#. It is not nearly as much fun or
as flexible or as good as C++/CLI IMO. But Microsoft clearly has little
interest in promoting or supporting C++/CLI any more as a first class
..Net language. And I have no interest in programming in a second class
..Net language. I have been through that with Borland already and I am
not going through that with Microsoft.

 

[David Lowndes]

I

always implement a "using" statement for any object that implements
"IDisposable"

Larry,

How does anyone know whether they should use a "using" statement
block? Other than using the object browser I don't know of any way of
ascertaining if it's necessary or not (since we can't trust the
documentation).

and you can even write it as "using (yourObject as
IDisposable)", just in case "IDisposable" isn't implemented

Why ever would you want to do that?

(though you normally know it is)

I don't know. Other than by intuition there's no way to know without
investigation.

Merry Christmas
Dave

 

[Larry Smith]

It offers a model by which C++ programmers can program .Net. There is

nothing seriously wrong with C#, and it has many good features. My OP was
about Microsoft specifically creating a C++ dialect to program .Net, which
they promoted and touted as an alterative to C# as well as a means to use
native C++ also, and then refusing to grant C++/CLI the same first-rate
status as C# as a .Net programming language.

I hear you and agree on that point.

The major plus of C++/CLI over C# is that it is possible to interface with
native C++ 3rd party libraries, including the C++ standard library.

I don't believe most people working in .NET are dealing with these issues.
It's a relatively new platform and most projects are likely new as well.
Leveraging existing C++ code may be a factor for some but I doubt there's a
huge migration of C++ code to .NET (or a reliance on C++ techniques in
general)

The second major advantage is the ability to deal with C++ templates on
the native C++ side. While .Net generics are a good job by Microsoft, they
are not as good as C++ templates in many ways, while being currently
better in just a few.

This is also a trivial issue for most IMO. Most people don't use complicated
template scenarious even in unmanaged C++ so generics will usually suffice
in most cases (and it does in fact IMO). The issue is moot anyway. I've
already stated that C# was a mistake but now that it's here and it's the
predominant .NET language, most companies will have a much easier time
abandoning C++ on this platform.

I do not agree at all with your idea that adding native C++ to .Net
programming creates additional problems.

Of course it will. Big expensive problems. C++ is a very complicated
language that most people can't handle outside of .NET. Now you want to
support an application that requires C++ skils and .NET skills? So your app
is going to rely on what exactly, both native C++ collections and .NET
collections? "IEnumerable" and C++ iterators. Generics and C++ templates.
Native C++ objects and managed objects. All of this unnecessarily introduces
two sets of paradigms into one application and that will surely lead to
problems. Even just finding competent C++ developers who can handle all this
will be difficult. It's getting more difficult to find experienced C++
developers even for native WinAPI projects. They're a declining breed IOW.
With C# however, everything deals directly with the framework. There are no
extraneous language issues to deal with unlike C++ and most development is
either now moving in that direction or will eventually be forced to.

By those terms Microsoft should never have created or promoted C++/CLI as
a language to program .Net. But they did and they clearly have relegated
it to a second-class language.

I fully agree with you here. It was disingenuous of MSFT.

When I bring that up I just

hear the weary "What's done is done however and you'll have to live
with it as we all do."

What would you have us do. You're not going to rally people to head to
Redmond so they can throw eggs at Bill Gates window. It's not an attitude
problem of sheepish people either. MSFT introduced C# and it's here. Most
are using it for .NET development and having two competing languages around
(forgetting about VB) is problematic. C# was designed from the ground up to
work with .NET and it's a perfectly legitimate language for the task. I'm a
hardcore C++ developer with far more experience than most but I recognize
the game's been lost. C# just marched onto the field and was declared the
winner. It's generally accepted now and the decision won't be reversed.

 

[Larry Smith]

I

Larry,

How does anyone know whether they should use a "using" statement
block? Other than using the object browser I don't know of any way of
ascertaining if it's necessary or not (since we can't trust the
documentation).

My issue with the docs has mostly been a lack of sufficient information. On
this front they're woefully inadequate (frequently anyway). However, I don't
ever recall encountering a documented class hierarchy that was incorrect.
Maybe I've just been too trusting however. In any case, you can quickly
discover if a class implements "IDisposable" by looking at its definition in
code (via the "GoToDefinition" command typically). The issue of
"IDisposable" is nevertheless a very tiny one in the grand scheme of things.
IMHO it's no reason to pick C++ over C# though again, C++ should have been
used in the first place.

Why ever would you want to do that?

interface ISomeInterface
{
// ...
}

class Whatever : ISomeInterface, IDisposable
{
public void Dispose()
{
// ...
}
};

ISomeInterface someObject = new Whatever();
using (someObject as IDisposable)
{
// ...
}

This won't compile without the "as IDisposable" as seen. It's safe though if
"IDisposable" isn't actually implemented on "Whatever" since null is then
returned in the "using" statement (which is tested for in the underlying
"finally" block and safely ignored). Of course it's still very ugly compared
to C++.

I don't know. Other than by intuition there's no way to know without
investigation.

Just look at the class hierarchy if not the docs themselves. Interfaces pose
a greater difficulty however as per the previous example (which can actually
cause overt and/or subtle bugs - if you don't call "Dispose()" on an
interface when the situation calls for it, the resource may never be
disposed of and this can lead to big trouble potentially)

 

[Tomas]

I am totally agree with you.
C++/CLI has become a second class language.
C++/CLI is dead, God saves C++/CLI.

 

[Ben Voigt [C++ MVP]]

I know C#, Java, and Python very well, thank you.

So it is absolutely normal to you that C++/CLI, despite being a version of
C++ expressly created for .Net programming, should not have the same

No, it is not!

It is designed expressly to bridge the gap between .NET and native code,
whether internal implementation of the BCL, advanced use of Win32 APIs, or
existing C++ libraries.

It does that very well. Any future improvements are focused on doing that
better (bridging generics with STL containers, etc).

End of story.

 

[David Ching]

Not working for MS in a position to really know, I (and I presume
*we*) don't know what their reasons are other than via propaganda -
they could be to tie companies into a proprietary language/OS

Merry Christmas
Dave

Good point that we don't really know for sure. But say the reason were to
tie us to a proprietary language/OS. They could do that by creating a
Borland C++Builder-like environment which is native and still proprietary.
So locking us into a proprietary environment alone does not explain why they
pushed managed.

-- David

 

[David Ching]

They made the market the way it is by their poor support for C++ .Net.
Then after doing that, and everything they could do to promote C#, they
cleverly argue that because there is little market for it, there is no
point in supporting it. It is a self-fulfilling prophecy, as they saying
goes.

Borland did the same thing for C++ Builder. They negelected it for years
in favor of Delphi, their own language and product, and then they said
that because there was a small market for it they were not going to
support it very much.

It amazes me how C++ programmers can not see how obvious this pattern is.

From our point of view, the company's neglect has contributed, but I still
think you are missing something huge: if the marketplace had been more
receptive, the company would not have neglected it. And it was not entirely
because the offerings were crap that the market (us) ignored the product.
VS2005 was not crap. For WinForms development, it was spot on (the
designers needed help, but they were functional). And still how many
C++/CLI WinForms apps were created in the last 2 years since VS2005 was
released? Not enough to make me choose C++/CLI for the best support and
momentum.

That's a key word: momentum. Momentum is what made C++ great. It offered
great functionality and a great community of people using it. People wanted
to program in C++ for these benefits. And momentum is the reason why
C++/CLI people are now using C#. C++ programmers love momentum more than
C++ itself.

So I think you are only seeing half the pattern.

-- David

 

[David Ching]

What's the issue here. You simply check the docs or look at the class
hierarchy itself. It's also a trivial issue to test for it in code if you
need to for some reason. That's usually not req'd though. In any case, the
"using" statement is a trivial issue in the grand scheme of things. It
really only applies to objects holding unmanaged resources and it's no
reason to choose C++ over C#.

You think it's not an issue for us lazy programmers used to Intellisense to
"check the docs or look at the class hierarchy itself"? Come to think
of it, that would be a great Intellisense feature: draw a red squiggly
underneath a declaration of an IDiposable class that does not have a 'using'
statement. David L - want to fill out a Connect request for this? (You're
the Connect King)....

-- David

 

[David Ching]

I do not really care that much what the differences between C++ and C#
are. I only care that Microsoft, and the likes of Lippman and Sutter, went
out of their way to tout C++/CLI as a programming language for .Net for
C++ programmers, only to drop it like a hot potato when they decided that
C# would be the way to go for all of the key .Net technologies.

They wasted my time and my efforts and I am sure they did so for many C++
programmers. My OP is a reflection of that reality.

I understand how it must have been a jolt to anticipate VS2008 and find out
when it was released that support of your language of choice, C++/CLI, is
not as expected. If I had invested a lot of time and code into C++/CLI, I
would feel let down as well. But, step back and ask, how exactly were your
time and efforts wasted? All your C++/CLI code still works and interops
with little effort with C#. You can continue developing the code in
C++/CLI, and only new features like XAML will not be accessible. I can't
see how one line of code that you wrote is rendered unusable. Lippman's and
Sutter's et al.'s contributions live on.

Not that you necessarily should have known, or that it would necessarily
have made a difference, but
http://channel9.msdn.com/Showpost.aspx?postid=281987 said as early as
February, 2007 that C++/CLI would be focused on Interop and things like Linq
would not be supported.

I can very adequately program using C#. It is not nearly as much fun or as
flexible or as good as C++/CLI IMO. But Microsoft clearly has little
interest in promoting or supporting C++/CLI any more as a first class .Net
language. And I have no interest in programming in a second class .Net
language. I have been through that with Borland already and I am not going
through that with Microsoft.

Due to the better tools, C# is more fun than C++/CLI.

-- David

 

[David Ching]

No, it is not!

It is designed expressly to bridge the gap between .NET and native code,

That is the case now, but in fairness to Edward, that was not the stated
initial goal back in VS2005 timeframe. Back then, the goal was to be a
better language to develop .NET apps than C# (and they boasted about
superior compiler optimizations).

-- David

 

[Ben Voigt [C++ MVP]]

What would you have us do. You're not going to rally people to head to

Redmond so they can throw eggs at Bill Gates window. It's not an attitude
problem of sheepish people either. MSFT introduced C# and it's here. Most
are using it for .NET development and having two competing languages
around (forgetting about VB) is problematic. C# was designed from the
ground up to

They aren't competing, they are complementary.

C# is Microsoft's baby, they can add LINQ and anything else without having
to fight some standards committee to use the name (I'm surprised no one has
told Microsoft to change the labels on the examples from VB/C#/C++ to
...../C++-CLI).

work with .NET and it's a perfectly legitimate language for the task. I'm
a hardcore C++ developer with far more experience than most but I
recognize the game's been lost. C# just marched onto the field and was
declared the winner. It's generally accepted now and the decision won't be
reversed.

C# has fancy WPF and Forms and ASP and database designers.

But just try enumerating the device manager tree using C#. That would be
suicidally stupid, you'd need a lot more code than C++/CLI and there'd be a
lot more potential for app-crashing mistakes (bad p/invoke declarations, bad
use of the Marshal.* APIs, etc) not to mention no debugger support for
introspection of pointers to native structures.

Maybe some future version of the BCL will include support for device
enumeration and hotplug events. If so, it's almost certain it will be
written in C++/CLI as distributed as an assembly for use from C#, just like
I do today to access that functionality.

 

[Larry Smith]

What's the issue here. You simply check the docs or look at the class

You think it's not an issue for us lazy programmers used to Intellisense
to
"check the docs or look at the class hierarchy itself"? Come to think
of it, that would be a great Intellisense feature: draw a red squiggly
underneath a declaration of an IDiposable class that does not have a
'using'
statement. David L - want to fill out a Connect request for this?
(You're
the Connect King)....

This has nothing to do with "guesswork" which is the focus of this
particular thread. And yes you should check the docs before using anything.
You don't rely on code to officially establish things. A compiler warning
would also be a more realistic alternative here (in addition to whatever
visual cues may be possible) since a "using" statement isn't mandatory or
even necessarily called in the same function where you create the object.

 

[Larry Smith]

What would you have us do. You're not going to rally people to head to

They aren't competing, they are complementary.

Nonsense. Who uses C# to complement C++. It's the other way around and only
then to deal with legacy code and gaps in the framework. Outside of this the
two languages do in fact compete.

C# is Microsoft's baby, they can add LINQ and anything else without having
to fight some standards committee to use the name (I'm surprised no one
has told Microsoft to change the labels on the examples from VB/C#/C++ to
..../C++-CLI).


C# has fancy WPF and Forms and ASP and database designers.

No it doesn't. The framework does. C# is just a symbolic language no
different than C++.

But just try enumerating the device manager tree using C#. That would be
suicidally stupid, you'd need a lot more code than C++/CLI and there'd be
a lot more potential for app-crashing mistakes (bad p/invoke declarations,
bad use of the Marshal.* APIs, etc) not to mention no debugger support for
introspection of pointers to native structures.

Maybe some future version of the BCL will include support for device
enumeration and hotplug events. If so, it's almost certain it will be
written in C++/CLI as distributed as an assembly for use from C#, just
like I do today to access that functionality.

One unified language and a complete framework would have solved everyone's
problems from the get-go. The WinAPI is in desperate need of a complete
overhaul now anyway. Sooner or later MSFT will have to face this so they
should just bite the bullet and do it. Maybe .NET will eventually morph into
that but two languages just aren't needed in the real world.

 

[Edward Diener]

No, it is not!

It is designed expressly to bridge the gap between .NET and native code,
whether internal implementation of the BCL, advanced use of Win32 APIs, or
existing C++ libraries.

It does that very well. Any future improvements are focused on doing that
better (bridging generics with STL containers, etc).

End of story.

How nicely to just "end the story" once technology is redefined to your
own ends. There was never the slightest talk of C++/CLI being designed
simply to bridge the gap between .NET and native code ( by which I have
to assume you mean the native Windows API ) and it is nonsense to
interpret it that way since .Net interop also does the exact same thing.

There was a great deal of talk and hype and promotion, especially by
Herb Sutter, but also by Stan Lippman, of C++/CLI being a language for
C++ programmers to access the .Net framework, with the unspoken
assumption that the VC++ team would make sure that C++ programmers would
have the same facilities to do so as any other .Net language else why
should C++ programmers bother to learn and use it.

That lie has now been exposed in the latest VS 2008 release and by the
remarks of members of the VC++ team and now we find out that C++/CLI,
all of a sudden, was never meant to be a first class language to access
..Net.

In the face of the sudden change of direction for C++/CLI it is
fruitless to continue it for mainstream .Net programming. I will
continue to use VC++ for native Windows programming tasks, as I do at my
job, but there is no question that using C++/CLI for .Net programming is
now largely a wasted task.

I have already used previously a C++ extended language which was treated
as a second class programming language in another RAD environment and I
do not tend to do so again.

 

[Edward Diener]

They aren't competing, they are complementary.

C# is Microsoft's baby, they can add LINQ and anything else without having
to fight some standards committee to use the name (I'm surprised no one has
told Microsoft to change the labels on the examples from VB/C#/C++ to
..../C++-CLI).

Both C# and C++/CLI are ECMA standards. The 'saw' about Microsoft being
able to change C# but not being able to change C++/CLI is absurd. You
might as well say that Microsoft has to fight ECMA to change C#, but I
did not notice any great fight occurring for the latest release of C#,
did you ?

C++/CLI is not C++. It is an extension to the C++ language with a great
deal of its own added language for the purpose of .Net programming. Any
changes made to C++/CLI to support .Net would be made strictly on the
CLR side of things, not on the native C++ constructs. I heavily doubt
that the C++ standards committee is going to put any roadblocks in front
of Microsoft for changing CLR constructs in C++/CLI to support new .Net
features.

The VC++ team did an admirable job with STL/CLR but I see little
improvements in 3 years in anything else that could matter to me. on the
C++/CLI side they did not support new .Net technologies such as WPF,
WCF, WWF, and LINQ and they even removed .Net technologies they
previously supported ( Web Services ). They also removed support for
the non-.Net ATL Server technology, which was the only advanced web
server technology they had left since they never supported ASP .Net.

It is hard for me to believe that improving MFC instead of improving
..Net programming should have been the focus of the VC++ team in the year
2008. I am sure it is helpful to those C++ programmers who are still
working with lagacy MFC applications, but I view .Net as a huge step
above MFC in overall programming technology. Since I am pretty unhappy
with the focus VC++ took toward the past, I sure hope people programming
MFC are happy with what they got. Of the mainstream VC++ technologies,
..Net programming, standard C++ programming, and MFC programming I view
the latter as easily the poorest of the lot.

 

[Ben Voigt [C++ MVP]]

How nicely to just "end the story" once technology is redefined to your
own ends. There was never the slightest talk of C++/CLI being designed
simply to bridge the gap between .NET and native code ( by which I have to
assume you mean the native Windows API ) and it is nonsense to interpret
it that way since .Net interop also does the exact same thing.

I do not just mean the native Windows API, although that's a substantial
value. Also, .NET interop may be the underlying layer (unless compiling
with /clr and not /clrure) but only the C++/CLI compiler brings you
interop in a usable package. And C++/CLI is the only way to go if you need
mixed-mode, p/invoke simply cannot interop with a non-COM C++ library.

There was a great deal of talk and hype and promotion, especially by Herb
Sutter, but also by Stan Lippman, of C++/CLI being a language for C++
programmers to access the .Net framework, with the unspoken assumption
that the VC++ team would make sure that C++ programmers would have the
same facilities to do so as any other .Net language else why should C++
programmers bother to learn and use it.

That lie has now been exposed in the latest VS 2008 release and by the
remarks of members of the VC++ team and now we find out that C++/CLI, all
of a sudden, was never meant to be a first class language to access .Net.

As I understood it, it was hyped for library development, for extending the
MS-provided framework. It excels at that.

 

[Ben Voigt [C++ MVP]]

Both C# and C++/CLI are ECMA standards. The 'saw' about Microsoft being
able to change C# but not being able to change C++/CLI is absurd. You
might as well say that Microsoft has to fight ECMA to change C#, but I did
not notice any great fight occurring for the latest release of C#, did you
?

C++/CLI is not C++. It is an extension to the C++ language with a great
deal of its own added language for the purpose of .Net programming. Any
changes made to C++/CLI to support .Net would be made strictly on the CLR
side of things, not on the native C++ constructs. I heavily doubt that the
C++ standards committee is going to put any roadblocks in front of
Microsoft for changing CLR constructs in C++/CLI to support new .Net
features.

Yes and no. It is a new language, however it maintains compatibility to the
point that any valid C++ program will compile under /clr (barring compiler
bugs, of which there are a few, but the language design does permit it).

 

[Ben Voigt [C++ MVP]]

Nonsense. Who uses C# to complement C++. It's the other way around and
only then to deal with legacy code and gaps in the framework. Outside of
this the two languages do in fact compete.

I do. I use C++/CLI for low-level device interactions, and C# for GUI
development and accessibility to other programmers. They complement each
other well.

No it doesn't. The framework does. C# is just a symbolic language no
different than C++.

Omit the word "designers" and you would be correct. However I said
designers and I meant designers.

 

[Larry Smith]

Nonsense. Who uses C# to complement C++. It's the other way around and

I do. I use C++/CLI for low-level device interactions, and C# for GUI
development and accessibility to other programmers. They complement each
other well.

You're using the term "complement" very loosely however. I could just as
well say that VB complements C++ on the GUI side. The real issue for me
however is the very presence of two languages. It makes the entire process
of developing software inherently more complicated and expensive.