Disappointment in VC++ .Net in VS2008

[David Lowndes]

If you've been using C# for 2 years, you'll presumably be familiar

I assume you're referring to the using "statement" for cleaning up resources
via "IDisposable" opposed to the using "directive"

Yes that's what I meant.

This is a relatively
trivial issue IMO and one that's fairly well-defined. I don't think there's
as much guess-work here as you're suggesting.

It sure seems like guesswork from my experience. I find myself
thinking ... now what's this class likely to be derived from
eventually... it probably needs a using statement, so put one in and
then see if it compiles or not. If it does, it was needed, if it
doesn't I remove it. Other than doing the code-analysis build, or
snooping around with the object browser, I've found the suck it and
see approach is often the quickest!

Sometimes there is but I think
it's more the fault of the .NET docs which are very weak IMO.

Oh don't get me started on that automatically generated twaddle that
passes for documentation of the .Net FW

I'm sure
C++/CLI has its own warts however and it's certainly no reason to pick
C++/CLI over C#.

It does indeed, one that's bitten me a few times is the fact that the
compiler lets you pass properties as modifiable values to functions
(the C# compiler tells you it won't work IIRC). I hope MS get that
fixed - it shouldn't be a fundamental issue like needing the using
statement.

Nevertheless, I've had to do some of my own nasty P/Invoking so your point
is well-taken. I don't think most developers have to go very far with it
however. If they do then they probably shoudn't be using .NET in the first
place.

Each real-world C# project I've seen has had some PInvokes in there.

Dave

 

[David Ching]

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

From what I gather, there was a struggle within Microsoft between the C++
camp and the C# camp about which language was to be the premier one for .NET
development. Around the VS2005 timeframe, the C++/CLI team had done a great
job of producing a fine language capable of doing everything C# could do, in
some cases with better optimization, and the dtor vs. 'using' scenario makes
it well loved by C++ programmers everywhere. So at that time, C++/CLI fully
deserved its title as a full-fledged .NET language. But that was for .NET
2.0.

Fast forward to .NET 3.5, with LINQ and XAML, anonymous methods, etc. .NET
had evolved in ways that were not necessarily easy to implement in C++/CLI,
and it seems that the C++/CLI team was always playing catch up with C#.
Meanwhile, all this effort to stay abreast in .NET was distracting from
satisfying the purely native C++ users. That's when I speculate the
decision was made to stop the goal of C++/CLI being a first class .NET
language. I think the effort to implement partial classes and LINQ was too
much.

My first .NET program was written in C++/CLI because it was enough to get
used to the framework and not worry about language differences. But every
program after that was in C#, and after working with C# for awhile I would
not want to program a .NET app in C++/CLI. If an existing C++ app needs to
use the .NET framework for some functionality (e.g. the XML parser in .NET
is really great), then it can easily do so with C++/CLI, so I think the
"new" role of C++/CLI to extend existing C++ apps is a wise one. It does
require making C++/CLI give up its title of the full-fledged .NET language,
though.

-- David

 

[David Ching]

I also appreciate some of those aspects, but ultimately feel that
there's nothing that couldn't have been done just as well (if the will
was there) in a native environment without the upset of .Net.

The only reason to push people to managed code, AFAIK, is to increase
security. We can all agree that is a high priority MS agenda item, yes?

-- David

 

[David Lowndes]

I also appreciate some of those aspects, but ultimately feel that

The only reason to push people to managed code, AFAIK, is to increase
security. We can all agree that is a high priority MS agenda item, yes?

I was waiting for someone to mention the S word

Yes, we all want security, but is it truly something that is anyone's
key reason for using managed code? I suspect not once it's been used
as a justification for playing with the latest toys is out of the way.

Dave

 

[Edward Diener]

OK, thanks, I was just inquisitive.

I also appreciate some of those aspects, but ultimately feel that
there's nothing that couldn't have been done just as well (if the will
was there) in a native environment without the upset of .Net.

A visual RAD environment for C++ needs run-time reflection, as well as
properties and events. Native C++ has none of these. The Boost Signals
library could easily serve as the 'event' part. The C++ standards
committee has shown no interest in run-time reflection or properties in C++.

Without these elements, especially run-time reflection, it would be very
difficult to build a visual RAD environment with C++.

Borland, who did it with C++ Builder, added run-time reflection,
properties, and events, borrowed from the Object Pascal based VCL, to
C++ by means of extensions.

Microsoft has added these elements to CLR and C++/CLI, which is an
extension of C++, implements CLR, so C++/CLI has these elements.

Now you and others will hopefully understand why it is so disappointing
that Microsoft is denigrating C++/CLI in order to force C++ programmers
to use C# instead.

There is absolutely nothing wrong with C++/CLI as a CLR languages and it
has, in a number of ways, a decided advantage over C#.

 

[Edward Diener]

From what I gather, there was a struggle within Microsoft between the C++
camp and the C# camp about which language was to be the premier one for .NET
development. Around the VS2005 timeframe, the C++/CLI team had done a great
job of producing a fine language capable of doing everything C# could do, in
some cases with better optimization, and the dtor vs. 'using' scenario makes
it well loved by C++ programmers everywhere. So at that time, C++/CLI fully
deserved its title as a full-fledged .NET language. But that was for .NET
2.0.

Fast forward to .NET 3.5, with LINQ and XAML, anonymous methods, etc. .NET
had evolved in ways that were not necessarily easy to implement in C++/CLI,
and it seems that the C++/CLI team was always playing catch up with C#.

LINQ and XAML has nothing to do with C# and everything to do with .Net.
It does not make sense, therefore, to say that the C++/CLI team was
always playing catch up with C#. It might make sense that they needed to
implement things in C++/CLI which was being added to .Net, but so did
the C# team. I do not call that playing catchup. It is only laziness on
the part of the VC++ team.

There is NO difference between the C# team adding features to the C#
language to accomodate new .Net features, if that is what they felt was
the way to support .Net, and the C++/CLI team adding features to C++/CLI
to accomodate new .Net features, if that is what they felt was the way
to support .Net. C++/CLI is not C+, it is Microsoft's own extension
purely to accomodate .Net, and they can change the language at will to
acoomodate new .Net features as they like. Both C# and C++/CLI are under
ECMA, so any excuse that they can add new features to C# but not to
C++/CLI is purely illusory.

Furthermore the C++/CLI team actually has the advantage over C# in that
they can use some of the greater facilities of their language, which is
based on C++, to add new features for .Net programming. The most
obvious advantage is templates in C++, but they also showed their mettle
in adding much better destructor syntax.

Meanwhile, all this effort to stay abreast in .NET was distracting from
satisfying the purely native C++ users. That's when I speculate the
decision was made to stop the goal of C++/CLI being a first class .NET
language. I think the effort to implement partial classes and LINQ was too
much.

This is purely your opinion or do you have firsthand knowledge of this ?

If the VC++ team is not talented enough or numerous enough to work on
both the native C++ front and the .Net front, Microsoft should either
hire more programmers for the VC++ team or get better people who want to
make C++ a first class native programming language and C++/CLI a first
class .Net programming language. The jokers they have now are a
disgrace, not because they are not talented but because they have
completely let down the C++/CLI programmers.

My first .NET program was written in C++/CLI because it was enough to get
used to the framework and not worry about language differences. But every
program after that was in C#, and after working with C# for awhile I would
not want to program a .NET app in C++/CLI.

And the reason is ?

If an existing C++ app needs to
use the .NET framework for some functionality (e.g. the XML parser in .NET
is really great), then it can easily do so with C++/CLI, so I think the
"new" role of C++/CLI to extend existing C++ apps is a wise one. It does
require making C++/CLI give up its title of the full-fledged .NET language,
though.

I have no idea why you think the '"new" role of C++/CLI to extend
existing C++ apps is a wise one'. I am either going to write a native
C++ application, or I am going to write a .Net application.

When C++/CLI was created it was touted as a way for C++ programmers to
write .Net applications and modules. Stan Lippmand and Herb Sutter did
an excellent job, vis-a-vis C++, of creating the language.

Now I find that all that hype about programming .Net with C++/CLI was a
baldfaced lie and Microsoft never had any attention of allowing C++
programmers to use the C++/CLI to write .Net applications and modules in
the same manner that C# programmers could.

When you say that you, as a C++ programmer, use C# rather C++/CLI to
program .Net you have done exactly as Microsoft wanted from the start,
which is to convert C++ programmers to C#. Congratulations ! I am sure
you are an excellent programmer but you are also a case study in how
well Microsoft has succeeded. I am not saying that C# is not a fine
language in its own way. I am just saying that thousands of C++
programmers were fooled into believing that C++/CLI would have all of
the ability and VS support for .Net programming as C# does, and now it
is evident that was just all a come on, and there was little truth in it.

 

[Larry Smith]

This is a relatively

It sure seems like guesswork from my experience. I find myself
thinking ... now what's this class likely to be derived from
eventually... it probably needs a using statement, so put one in and
then see if it compiles or not. If it does, it was needed, if it
doesn't I remove it. Other than doing the code-analysis build, or
snooping around with the object browser, I've found the suck it and
see approach is often the quickest!

I disagree. The "using" statement is nothing but a wrapper around a
"try/finally" block which automatically calls "IDisposable.Dispose()" 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
"IDisposable" and you can even write it as "using (yourObject as
IDisposable)", just in case "IDisposable" isn't implemented (though you
normally know it is). I strongly suggest getting hold of a copy of
"Programming .NET Components" by Juval Lowy if you don't already have one.
He's one of the world's leading authorities on .NET (as recognized by MSFT)
and he explains the entire pattern in exhaustive detail. The book itself is
a must-have for any serious developer (and I'm one of those who doesn't need
to turn to a lot of books)

Oh don't get me started on that automatically generated twaddle that
passes for documentation of the .Net FW

I'm *frequently* at a complete loss to understand how MSFT thinks developers
are supposed to work with it.

Each real-world C# project I've seen has had some PInvokes in there.

I can't speak to the frequency but I'm thankful for my deep C++ roots. Those
with no background in C++ and the WinAPI at all will have real and
potentially serious issues here. For me personally, I've had more
frustration with the lack of complete .NET analogues for some items in the
WinAPI. "GetOpenFileName()" and "GetSaveFileName()" immediately come to mind
as the corresponding .NET classes aren't extensible at all and provide
almost no customization. In this case you have no choice but to "P/Invoke"
to the latter WinAPI functions and those are painful functions to deal with
even in native C++. The mechanics of P/Invoke itself however are quickly
mastered by C++ developers. Nevertheless, the .NET framework itself is at
fault here. If that was fixed then C# would do just fine.

 

[David Ching]

LINQ and XAML has nothing to do with C# and everything to do with .Net. It
does not make sense, therefore, to say that the C++/CLI team was always
playing catch up with C#. It might make sense that they needed to
implement things in C++/CLI which was being added to .Net, but so did the
C# team. I do not call that playing catchup. It is only laziness on the
part of the VC++ team.

There is NO difference between the C# team adding features to the C#
language to accomodate new .Net features, if that is what they felt was
the way to support .Net, and the C++/CLI team adding features to C++/CLI
to accomodate new .Net features, if that is what they felt was the way to
support .Net. C++/CLI is not C+, it is Microsoft's own extension purely to
accomodate .Net, and they can change the language at will to acoomodate
new .Net features as they like. Both C# and C++/CLI are under ECMA, so any
excuse that they can add new features to C# but not to C++/CLI is purely
illusory.

I'm not an expert in language parsing, but it is generally acknowledged that
C# is easier to parse than C++ is. I would think that due to the native C++
parsing requirements that C++/CLI needs to support, any extensions to
accomodate LINQ and partial classes might be more difficult than the
equivalent changes in C#. In addition, the codebase for the C++ compiler is
very old and changes take longer. When it takes several years to revamp the
front end to support a better Intellisense (in Orcas+1), you get the idea
(again, just speculation) that things in the C++ team don't move very fast.

Furthermore the C++/CLI team actually has the advantage over C# in that
they can use some of the greater facilities of their language, which is
based on C++, to add new features for .Net programming. The most obvious
advantage is templates in C++, but they also showed their mettle in adding
much better destructor syntax.

Yes, and that is really nice, but not in itself a reason to use C++ for new
..NET apps.

This is purely your opinion or do you have firsthand knowledge of this ?

Just speculation, although based on what I hear as a Visual C++ MVP and
further verified by public Channel 9 videos. You certainly can't argue that
native C++ users weren't getting their needs met, hence the immenent
Orcas-but-a-little-late release of TR1.

If the VC++ team is not talented enough or numerous enough to work on both
the native C++ front and the .Net front, Microsoft should either hire more
programmers for the VC++ team or get better people who want to make C++ a
first class native programming language and C++/CLI a first class .Net
programming language. The jokers they have now are a disgrace, not because
they are not talented but because they have completely let down the
C++/CLI programmers.

Yes, I've also said this for some time. We both know that Microsoft has
enough resources to do this, so why don't they? I think the answer is
obvious: the payoff isn't there! Like it or not, there aren't enough
people like you who are interested in using C++/CLI as a first class .NET
language. I was once with you that I didn't want to use C#. But now I
don't want to use C++/CLI....

And the reason is ?

C# has a momentum for .NET apps that C++/CLI will never have (even if it
retained it's title as a first class .NET language). It had that title for
2 years and went nowhere with it. I am heavily investing in learning WPF
now, and that community is very, very C# oriented. It's easier to fit in.

Besides, the tools for C# are way better than for C++ (Resharper, etc.).
And a C# program is more readable than a C++/CLI program without all those
'^'.

I have no idea why you think the '"new" role of C++/CLI to extend existing
C++ apps is a wise one'. I am either going to write a native C++
application, or I am going to write a .Net application.

When C++/CLI was created it was touted as a way for C++ programmers to
write .Net applications and modules. Stan Lippmand and Herb Sutter did an
excellent job, vis-a-vis C++, of creating the language.

Well, they tried that, and like I said, C++/CLI as a pure .NET language
really didn't go very far in the marketplace (present company not
withstanding). Microsoft Bob also did not get very far, and I don't think
we cried much when they cancelled that (despite the fact that Melinda Gates
was a PM on that project). It's a business, after all. And I speculate
(only speculation) that Microsoft saw only two types of programmers wanting
C++/CLI: 1) native C++ programmers looking to use a familiar friend with
new .NET apps, and 2) native C++ programmers looking to extend legacy apps.
Since C# was designed to be easy for C++ programmers to learn, MS is not
going to lose much money by not supporting #1. #2 happens to have some very
large corporate accounts (including MS's own Windows team and other product
teams), so it makes sense to support them, which they are with C++/CLI in
its new role as a way of extending native apps to make use of .NET.

As I said, I once was one of C++/CLI's staunchest supporters. But really,
C++/CLI only makes sense if your basis is in C++ and you are looking to
extend into .NET. Otherwise, your basis is C# and you want to stay in .NET.
There are plenty of programmers coming into the workforce which know C# a
whole lot better than C++, and that trend is going to accelerate, just like
there aren't that many new programmers who know much 80x86 assembly
language. Microsoft isn't going to invest much money in keeping legacy
programmers since by definition, it's a shrinking market.

Now I find that all that hype about programming .Net with C++/CLI was a
baldfaced lie and Microsoft never had any attention of allowing C++
programmers to use the C++/CLI to write .Net applications and modules in
the same manner that C# programmers could.

I think one camp in Microsoft was very serious about it 2 years ago, but it
didn't work out. Life goes on.

When you say that you, as a C++ programmer, use C# rather C++/CLI to
program .Net you have done exactly as Microsoft wanted from the start,
which is to convert C++ programmers to C#. Congratulations ! I am sure you
are an excellent programmer but you are also a case study in how well
Microsoft has succeeded. I am not saying that C# is not a fine language in
its own way. I am just saying that thousands of C++ programmers were
fooled into believing that C++/CLI would have all of the ability and VS
support for .Net programming as C# does, and now it is evident that was
just all a come on, and there was little truth in it.

You make it sound like I drank Microsoft cool aid or something. That isn't
true. I am a consultant, and a businessman. I made a business decision to
develop in C#, because it is more productive and money saving due to the
better tools and third party support, and the learning curve was easily
accomodated. If I made Microsoft happy by doing that, I can think of worst
people to make happy. Microsoft has been good to me over the years. I've
made a lot of money (heck, 100% of my money) over my career on their
technologies, and they have always treated me well. It's not a sin to make
Microsoft happy, I don't know where you are going with that. I'm certainly
not going to boycott C# because they did an experiment with C++/CLI and due
to how that experiment turned out now want to go in a different direction
with it.

-- David

 

[David Ching]

I was waiting for someone to mention the S word

Yes, we all want security, but is it truly something that is anyone's
key reason for using managed code? I suspect not once it's been used
as a justification for playing with the latest toys is out of the way.

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.

-- David

 

[David Ching]

A visual RAD environment for C++ needs run-time reflection, as well as
properties and events. Native C++ has none of these. The Boost Signals
library could easily serve as the 'event' part. The C++ standards
committee has shown no interest in run-time reflection or properties in
C++.

Without these elements, especially run-time reflection, it would be very
difficult to build a visual RAD environment with C++.

Borland, who did it with C++ Builder, added run-time reflection,
properties, and events, borrowed from the Object Pascal based VCL, to C++
by means of extensions.

Microsoft has added these elements to CLR and C++/CLI, which is an
extension of C++, implements CLR, so C++/CLI has these elements.

Now you and others will hopefully understand why it is so disappointing
that Microsoft is denigrating C++/CLI in order to force C++ programmers to
use C# instead.

If Microsoft had did what Borland had done and just made a RAD environment
in C++ but entirely native code, then that would be worth preserving. As it
is, they did it in C++ but made it dependent on .NET, which has its own
issues with performance and deployability. 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.

-- David

 

[David Ching]

I disagree. The "using" statement is nothing but a wrapper around a
"try/finally" block which automatically calls "IDisposable.Dispose()" 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
"IDisposable"

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'? 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.Dispose() will be called
automatically. But in C# you have to arrange for it manually.

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.

Thanks,
David

 

[John Carson]

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

 

[Edward Diener]

If Microsoft had did what Borland had done and just made a RAD environment
in C++ but entirely native code, then that would be worth preserving.

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.

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 ?

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.

 

[David Ching]

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.

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

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

 

[Edward Diener]

I'm not an expert in language parsing, but it is generally acknowledged that
C# is easier to parse than C++ is.

I totally agree with that. However C++/CLI, as it is, is already parsed
by VC++.

I would think that due to the native C++
parsing requirements that C++/CLI needs to support, any extensions to
accomodate LINQ and partial classes might be more difficult than the
equivalent changes in C#.

It would be harder to parse but not harder to implement.

In addition, the codebase for the C++ compiler is
very old and changes take longer. When it takes several years to revamp the
front end to support a better Intellisense (in Orcas+1), you get the idea
(again, just speculation) that things in the C++ team don't move very fast.

Maybe the C++ compiler should be revamped to make it better if the
codebase is so old it can not be changed.

Yes, and that is really nice, but not in itself a reason to use C++ for new
.NET apps.

No, you missed my argument. I was saying that C++, because it is
inherently more flexible language than C#, might already provide the
facilities to add new .Net technologies without having to change the
language itself, whereas C# would have to change the language.
Traditionally C++ relies on its facilities, such as templates, to
provide features which other languages have to provide as a matter of
language additions.

Just speculation, although based on what I hear as a Visual C++ MVP and
further verified by public Channel 9 videos. You certainly can't argue that
native C++ users weren't getting their needs met, hence the immenent
Orcas-but-a-little-late release of TR1.

No, I do not argue that native C++ programmers are getting improvements
although even this area seems very modest to me. I argued that C++/CLI
..Net programmers have been totally let down by the VC++ team, and even
that this was Microsoft's plan from the beginning.

Yes, I've also said this for some time. We both know that Microsoft has
enough resources to do this, so why don't they? I think the answer is
obvious: the payoff isn't there! Like it or not, there aren't enough
people like you who are interested in using C++/CLI as a first class .NET
language. I was once with you that I didn't want to use C#. But now I
don't want to use C++/CLI....

The above is a self-creating situation. First Microsoft creates a poor
implementation for C++ .Net programming ( Managed C++ ) hile creating a
first class one for C#, with the added bonus that they have the serious
Loader Lock bug which keeps C++ .Net programmers from creating any mixed
mode assembly ( .Net 1.0 and .Net 1.1 ). Then Microsoft finally creates
a good language for C++ .Net programming ( C++/CLI ) but conveniently
leaves out the ability to use it with a major .Net technology ( ASP .Net
), have plenty of bugs using it with Visual Studio's RAD designers, and
finally tell people reporting these bugs that you are not going to be
fixing them ( .Net 2.0 ). Finally you say that C++/CLI is just not worth
it because too few people use it.

In other words, Microsoft first trashes C++ .Net programming in favor of
C# and then tells people that since very few people use it, they are not
going to waste their time supporting it. And everyone at Microsoft plays
along with the game and collects their paycheck while C++ programmers
suffer and Microsoft laughs.

C# has a momentum for .NET apps that C++/CLI will never have (even if it
retained it's title as a first class .NET language). It had that title for
2 years and went nowhere with it. I am heavily investing in learning WPF
now, and that community is very, very C# oriented. It's easier to fit in.

Besides, the tools for C# are way better than for C++ (Resharper, etc.).
And a C# program is more readable than a C++/CLI program without all those
'^'.

See above for why all this is so.

As for readability I agree with you that C# is more readable, but not by
a whole lot. But a simpler language to understand is not necessarily better.

Well, they tried that, and like I said, C++/CLI as a pure .NET language
really didn't go very far in the marketplace (present company not
withstanding). Microsoft Bob also did not get very far, and I don't think
we cried much when they cancelled that (despite the fact that Melinda Gates
was a PM on that project). It's a business, after all. And I speculate
(only speculation) that Microsoft saw only two types of programmers wanting
C++/CLI: 1) native C++ programmers looking to use a familiar friend with
new .NET apps, and 2) native C++ programmers looking to extend legacy apps.
Since C# was designed to be easy for C++ programmers to learn, MS is not
going to lose much money by not supporting #1. #2 happens to have some very
large corporate accounts (including MS's own Windows team and other product
teams), so it makes sense to support them, which they are with C++/CLI in
its new role as a way of extending native apps to make use of .NET.

As I said, I once was one of C++/CLI's staunchest supporters. But really,
C++/CLI only makes sense if your basis is in C++ and you are looking to
extend into .NET. Otherwise, your basis is C# and you want to stay in .NET.
There are plenty of programmers coming into the workforce which know C# a
whole lot better than C++, and that trend is going to accelerate, just like
there aren't that many new programmers who know much 80x86 assembly
language. Microsoft isn't going to invest much money in keeping legacy
programmers since by definition, it's a shrinking market.

You argue the party line very well.

I think one camp in Microsoft was very serious about it 2 years ago, but it
didn't work out. Life goes on.



You make it sound like I drank Microsoft cool aid or something. That isn't
true. I am a consultant, and a businessman. I made a business decision to
develop in C#, because it is more productive and money saving due to the
better tools and third party support, and the learning curve was easily
accomodated. If I made Microsoft happy by doing that, I can think of worst
people to make happy. Microsoft has been good to me over the years. I've
made a lot of money (heck, 100% of my money) over my career on their
technologies, and they have always treated me well. It's not a sin to make
Microsoft happy, I don't know where you are going with that. I'm certainly
not going to boycott C# because they did an experiment with C++/CLI and due
to how that experiment turned out now want to go in a different direction
with it.

C# is a fine language, so stay with it.

 

[John Carson]

No, I do not argue that native C++ programmers are getting improvements
although even this area seems very modest to me. I argued that C++/CLI
.Net programmers have been totally let down by the VC++ team, and even
that this was Microsoft's plan from the beginning.

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.

The above is a self-creating situation. First Microsoft creates a poor
implementation for C++ .Net programming ( Managed C++ ) hile creating a
first class one for C#, with the added bonus that they have the serious
Loader Lock bug which keeps C++ .Net programmers from creating any mixed
mode assembly ( .Net 1.0 and .Net 1.1 ). Then Microsoft finally creates a
good language for C++ .Net programming ( C++/CLI ) but conveniently leaves
out the ability to use it with a major .Net technology ( ASP .Net ), have
plenty of bugs using it with Visual Studio's RAD designers, and finally
tell people reporting these bugs that you are not going to be fixing them
( .Net 2.0 ). Finally you say that C++/CLI is just not worth it because
too few people use it.

In other words, Microsoft first trashes C++ .Net programming in favor of
C# and then tells people that since very few people use it, they are not
going to waste their time supporting it.

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.

As for readability I agree with you that C# is more readable, but not by a
whole lot. But a simpler language to understand is not necessarily better.

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

john carson

 

[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

 

[David Lowndes]

A visual RAD environment for C++ needs run-time reflection

The run-time reflection does make several features of a RAD seamless,
but they come at a cost to everything - you don't get something for
nothing.

I was suggesting that a much better native development tool could have
been achieved with less duplication of effort and less heartache than
..Net - if the will had been there.

Now you and others will hopefully understand why it is so disappointing
that Microsoft is denigrating C++/CLI in order to force C++ programmers
to use C# instead.

You think I'm not disappointed already (and have been for a long time)
that MS have not used C++ as the default managed language? I was, and
still am, greatly disappointed that I can't use C++/CLI for the things
I'm finding I now use C# for!

There is absolutely nothing wrong with C++/CLI as a CLR languages and it
has, in a number of ways, a decided advantage over C#.

I agree entirely.

Merry Christmas
Dave

 

[Edward Diener]

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

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.Dispose() 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 "IDisposable" so you should explicitly invoke "Dispose()",
normally via the "using" statement.