Disappointment in VC++ .Net in VS2008

[Edward Diener]

Why bother having Stan Lippman and Herb Sutter created a C++/CLI
language for .Net development when Microsoft, and the VC++ development
team, are so clearly intent on limiting .Net development with C++/CLI to
the smallest subset of .Net development technologies in Visual Studio,
while all of the new technologies are given to C# instead ? The bubble
has burst with VS 2008 and we are instead finally told quite frankly, by
a lead VC++ team developer, that VC++ is not going to be a first-class
..Net development language. In that case why bother with C++/CLI, since
it serves little to no purpose for C++ programmers anymore. Here is the
lineup:

1) ASP .NET, not for C++
2) Web services in .Net, not for C++ and even web services client
development is removed in VS 2008.
3) WPF, not for C++ and even creating controls for WPF is absent for
C++/CLI.
4) WCF, not for C++.
5) WWF, not for C++
6) LINQ, not for C++.

Finally all advanced web application development is remove from C++ with
the abandonment of the ATL Server.

VS 2008 is an abortion for C++ .Net developers in every way. The message
is now clear from Microsoft and the pretense is finally dropped "If you
want to do .Net development in C++, just forget about it and start
programming in C#". It should have been clear from the beginning, with
the miraculously appearing loader lock bug, but now is transparent.

Instead the big news in VC++ for VS 2008 is Vista updates for MFC of all
technologies. Gee, I am sure glad I learned a RAD technology like .Net
so I could go back to doing MFC development.

C++/CLI is such a good language, with so much careful and intelligent
decisions made so that it is superior to C# in almost every way, that it
is sad to finally realize that Microsoft never had any plans for C++
developers to effectively compete with C# developers in the .Net world.
It was just a sop so that they could attract C++ developers and turn
them toward C#.

Stan Lippman, Herb Sutter, Brandon Bray, and others, you should all be
ashamed of yourselves in leading VC++ straight to a dead end of
programming for .Net.

[John Carson]

"Edward Diener" <ed************ *******@tropics oft.comwrote in message
news:uC******** *****@TK2MSFTNG P04.phx.gbl...

David Lowndes wrote:

>>It will make it happen if enough C++ programmers voice their displeasure
and refuse to spend their money. Microsoft is not stupid and they do
react to market forces.

Which is presumably why they've decided to re-emphasise MFC - albeit
just buying in and reworking a 3'rd party library.

MFC, no matter how many Microsoft C++ programmers have worked with it, is
a poor C++ application framework.

That may be, but you are changing the subject. There is a huge amount of MFC
code out there and Microsoft was responding to market forces in deciding to
further develop MFC, just as they were responding to market forces in giving
renewed emphasis to native code more generally.

I don't disagree with you that it would be great to see *both* better
support for native code *and* top class support for C++/CLI. However, MS has
plainly assessed the market and decided that that is not the way to go.

john carson

[David Ching]

"Edward Diener" <ed************ *******@tropics oft.comwrote in message
news:O%******** ********@TK2MSF TNGP06.phx.gbl. ..

No, Borland's version of C++ is not entirely native code. Borland added
extensions to support their RAD programming model. You can not take a C++
Builder programmer and just compile it anywhere, or run it without the VCL
libraries.

Then the equivalent would be for Microsoft to do the same with MFC.

>As it is, they did it in C++ but made it dependent on .NET, which has its
own issues with performance and deployability.

C++ Builder is dependent on the VCL libraries. How is that different from
C++/CLI dependent on .NET ?

..NET has an inherent performance hit that is not apparent in VCL or any
native library. .NET is hard to deploy, requiring the latest MSI Installer
which if not present requires a reboot, and plus .NET libraries are huge ~25
MB. Both VCL and MFC are capable of being compiled into the .exe for single
..exe deployment. The deployment issue is the single most reason why .NET is
not more accepted in the marketplace (although that is changing).

> As it is, the minor improvements that C++/CLI has over C# (significant
improvements , especially if you already know C++, no doubt, but minor
compared to them not making it native code) do not make it worth
perserving, as a first class Visual RAD language, IMHO.

You make that statement above with no reason behind it, as if you were
just quoting the VC++ team's own opinion.

The only worthwhile thing that I have found so far which I miss in C++/CLI
is the dtor. The other so-called advantages of better optimization and
other stuff mentioned in this thread are nothing to shed tears over, IMHO.

-- David

[David Lowndes]

>Let me clarify: OUR reason to use C# is for the latest toys. MS'S reason

>for wanting us to use C# (managed code) is to increase security in the
Windows ecosystem and thus reduce its costs associated with malware.

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

[Edward Diener]

John Carson wrote:

"Edward Diener" <ed************ *******@tropics oft.comwrote in message
news:uC******** *****@TK2MSFTNG P04.phx.gbl...

>David Lowndes wrote:

>>>It will make it happen if enough C++ programmers voice their displeasure
and refuse to spend their money. Microsoft is not stupid and they do
react to market forces.
Which is presumably why they've decided to re-emphasise MFC - albeit
just buying in and reworking a 3'rd party library.

MFC, no matter how many Microsoft C++ programmers have worked with it, is
a poor C++ application framework.

That may be, but you are changing the subject. There is a huge amount of MFC
code out there and Microsoft was responding to market forces in deciding to
further develop MFC, just as they were responding to market forces in giving
renewed emphasis to native code more generally.

I don't disagree with you that it would be great to see *both* better
support for native code *and* top class support for C++/CLI. However, MS has
plainly assessed the market and decided that that is not the way to go.

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.

[Larry Smith]

>I disagree. The "using" statement is nothing but a wrapper around a

>"try/finally" block which automatically calls "IDisposable.Di spose()" for
releasing unmanaged resources (normally). While there are some issues
with the pattern in general, I've never found them to be a problem in
practice. I always implement a "using" statement for any object that
implements "IDisposabl e"

This is the issue. How do you easily determine whether an object
implements IDisposable and therefore any instance you create needs to be
surrounded with 'using'?

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

In C++/CLI the syntax is the same no matter if it implements IDisposable
or not, therefore you just instantiate the object and use, confident that
if required, IDisposable.Dis pose() will be called automatically. But in
C# you have to arrange for it manually.

Agreed and I've already previously stated that the "using" statement is ugly
compared to C++ destructors. The over-arching issue however is that C++ just
isn't needed IMO. I've already stated that C# was a mistake in the first
place however (they should have stuck with C++), but now that C# is here,
C++ isn't required in the .NET world (except when dealing with legacy code).

BTW, does the new SafeHandle take care of any of this? Native Win32
handles are a large percentage of things which need to be disposed.

It implements "IDisposabl e" so you should explicitly invoke "Dispose()" ,
normally via the "using" statement.

[=?Utf-8?B?VG9tYXM=?=]

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

--
Tomas
English is not my first language.
Excuse me the inconvenients.
"Edward Diener" wrote:

Why bother having Stan Lippman and Herb Sutter created a C++/CLI
language for .Net development when Microsoft, and the VC++ development
team, are so clearly intent on limiting .Net development with C++/CLI to
the smallest subset of .Net development technologies in Visual Studio,
while all of the new technologies are given to C# instead ? The bubble
has burst with VS 2008 and we are instead finally told quite frankly, by
a lead VC++ team developer, that VC++ is not going to be a first-class
..Net development language. In that case why bother with C++/CLI, since
it serves little to no purpose for C++ programmers anymore. Here is the
lineup:

1) ASP .NET, not for C++
2) Web services in .Net, not for C++ and even web services client
development is removed in VS 2008.
3) WPF, not for C++ and even creating controls for WPF is absent for
C++/CLI.
4) WCF, not for C++.
5) WWF, not for C++
6) LINQ, not for C++.

Finally all advanced web application development is remove from C++ with
the abandonment of the ATL Server.

VS 2008 is an abortion for C++ .Net developers in every way. The message
is now clear from Microsoft and the pretense is finally dropped "If you
want to do .Net development in C++, just forget about it and start
programming in C#". It should have been clear from the beginning, with
the miraculously appearing loader lock bug, but now is transparent.

Instead the big news in VC++ for VS 2008 is Vista updates for MFC of all
technologies. Gee, I am sure glad I learned a RAD technology like .Net
so I could go back to doing MFC development.

C++/CLI is such a good language, with so much careful and intelligent
decisions made so that it is superior to C# in almost every way, that it
is sad to finally realize that Microsoft never had any plans for C++
developers to effectively compete with C# developers in the .Net world.
It was just a sop so that they could attract C++ developers and turn
them toward C#.

Stan Lippman, Herb Sutter, Brandon Bray, and others, you should all be
ashamed of yourselves in leading VC++ straight to a dead end of
programming for .Net.

[David Ching]

"Edward Diener" <ed************ *******@tropics oft.comwrote in message
news:%2******** ********@TK2MSF TNGP03.phx.gbl. ..

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]

"Edward Diener" <ed************ *******@tropics oft.comwrote in message
news:e1******** ******@TK2MSFTN GP03.phx.gbl...

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]

"David Lowndes" <Da****@example .invalidwrote in message
news:ur******** *************** *********@4ax.c om...

Let me clarify: OUR reason to use C# is for the latest toys. MS'S
reason
for wanting us to use C# (managed code) is to increase security in the
Windows ecosystem and thus reduce its costs associated with malware.

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]

"Larry Smith" <no_spam@_nospa m.comwrote in message
news:ub******** ******@TK2MSFTN GP03.phx.gbl...

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