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.

 

[Tom Walker]

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

What's wrong with you? If you know only one programming language you are a
dinosaur. Use C++ when appropriate. Use C# when appropriate. Use other
languages when appropriate. Stop being anal. Get over it. Move on. Happy
Holidays.

 

[Edward Diener]

What's wrong with you? If you know only one programming language you are
a dinosaur. Use C++ when appropriate. Use C# when appropriate. Use other
languages when appropriate. Stop being anal. Get over it. Move on. Happy
Holidays.

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
visual programming support in the Visual Studio IDE for mainstream .Net
technologies that C# and VB .Net have, and that anyone using those
mainstream technologies will almost certainly program them using C# and
VB .Net.

This was the gist of my OP. While you have a good point that one should
be flexible in learning more than one programming language, I think it
is quite normal for programmers to be disappointed when the promise and
hype of using a programming language soons becomes obsoleted by the very
same people who hyped and promised in the first place. C++/CLI was
created as a means for C++ programmers to be on equal footing when using
..Net technologies as C# and VB .Net programmers, else it is purely a
waste of time IMO. That was the promise but evidently the reality is
completely different.

Now we are told and most obviously shown in the current VS 2008 release
that it will not happen, that C++/CLI will be treated as a second class
..Net language, by the very same people who created and hyped C++/CLI in
the first place.

The C++ community has been tamed into a meek and mild acceptance of all
of the propaganda and false promises which come down from Microsoft and,
previously, Borland. If anyone objects to this second-class treatment in
relation to C# or VB .Net or Delphi, all inferior languages to C++, they
are told to get over it and move on.

I can easily program the .Net technologies in C#. It is a simple
language and supremely easy for an experienced C++ programmer such as
myself to use. After all, that is what Microsoft wanted in the first
place, to move C++ programmers to C# for the purpose of doing .Net
programming. C++/CLI I see now as essentially a ploy to throw C++ a bone
which will become more and more worthless to use as time goes on and all
new .Net technologies are co-opted toward C# ( and VB .Net ), despite
C++/CLI's superiority other .Net languages.

 

[David Lowndes]

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.

I agree, C++/CLI is a way better language than C# - and I could never
truly understand why Microsoft gave themselves the headache of
supporting 3 general purpose languages when 1 could have done it all.
IMHO they made lots of poor decisions with .Net - but it's all water
under the bridge now - isn't it?

At least we know they now know that people use C++ for developing all
aspects of Windows applications in the native code area - let's just
hope they don't forget that!

Dave

 

[Tom Walker]

The C++ community has been tamed into a meek and mild acceptance of all of
the propaganda and false promises which come down from Microsoft and,
previously, Borland. If anyone objects to this second-class treatment in
relation to C# or VB .Net or Delphi, all inferior languages to C++, they
are told to get over it and move on.

I don't recall hearing any promises that C++/CLI was supposed to be on equal
footing with C# and VB.NET in the .NET world. Personally, I think C++/CLI is
awesome technology and I'm glad to have it in my toolbox. But I don't want
Microsoft to rewrite their C++ compiler to support partial classes and all
of the new C# 3.0 features. I prefer the C++ compiler to be solid and
reliable.

And I don't see where you're coming from suggesting that there is ploy to
convert C++ programmers into C# programmers. Microsoft doesn't care what
programming language you use. C++ is not going away. Ever.

 

[Edward Diener]

I don't recall hearing any promises that C++/CLI was supposed to be on
equal footing with C# and VB.NET in the .NET world. Personally, I think
C++/CLI is awesome technology and I'm glad to have it in my toolbox. But
I don't want Microsoft to rewrite their C++ compiler to support partial
classes and all of the new C# 3.0 features. I prefer the C++ compiler to
be solid and reliable.

The word "promises" I used metaphorically. You don't have Stan Lippman
and Herb Sutter expostulating on how great a language C++/CLI is for
..Net programming without the assumption that it should be on an equal
footing with C# and VB .Net in the .Net programming world, and as well
supported for all areas of .Net programming. Now we find out with VS
2008 that C++/CLI is a second class .Net programming language and all
the effort for this release, which I personally see as precious little
from the VC++ team, is to be toward native Windows programming.

MFC is a huge step backward for .Net programmers, as it was a huge step
backward for this former ObjectWindows and C++ Builder programmer. So
all the touted improvements in MFC, while no doubt welcome to those
doing legacy MFC GUI programming, leaves this .Net programmer feeling
abandoned by VC++.

I am not recommending that C++/CLI mimic C#. It is, however, Microsoft's
own language and they can shape it as they want in order to program
..Net. Adding new language features to support .Net programming idioms
does not mean that C++/CLI does not stay reliable. In fact Microsoft
would make it more reliable if they actually fixed the bugs in C++/CLI
which I and many others have reported instead of saying that it is not
worth doing so for them.

However my OP had very little to do with C++/CLI as a language and
everything to do with the fact that Microsoft has limited, and now with
VS 2008, eliminated, areas in .Net for which C++/CLI could be applied,
while increasing the support for C# in those same areas. It hardly needs
no C++/CLI language features to support those areas, but if it
absolutely did, I would welcome it.

And I don't see where you're coming from suggesting that there is ploy
to convert C++ programmers into C# programmers. Microsoft doesn't care
what programming language you use. C++ is not going away. Ever.

You are ridiculously naive. If all the C++ programmers switch to C#, a
language created and controlled by Microsoft, rather than stay with C++,
a language which has a neutral body of people as its representatives,
you do not think this is good for Microsoft's profits ?

If you do not know that all software companies seek to have people use
their technologies at least in some part because it is good for their
revenue and success as a company, I can not comprehend in what world you
live. I acknowledge that most software companies, including Microsoft,
also take pride in the excellence and ideas of their technologies, but
it can hardly hurt them to sell their implementations as the ones for
which people pay money.

Saying that "Microsoft does not care what programming language you use"
is absurd. They would certainly care if programmers abandoned C# and VB
..Net and switched to C++, Java, Python, or Ruby and did cross-platform
or Macintosh or Linux programming instead of Windows programming.

 

[Edward Diener]

I agree, C++/CLI is a way better language than C# - and I could never
truly understand why Microsoft gave themselves the headache of
supporting 3 general purpose languages when 1 could have done it all.

..Net is supposed to be language agnostic as long as the language support
the CLR. This is a big part of Microsoft's selling point for it as
opposed to Java.

Since C++/CLI is Microsoft's own C++-like language for .Net they should
support it just as well as they support C# and VB .Net.

IMHO they made lots of poor decisions with .Net - but it's all water
under the bridge now - isn't it?

If you take a fatalistic attitude that what's done is done and can not
be corrected, then you are right. I do not agree. Technologies are
mutable and can always be changed for the better. Actually in only one
major area do i believe that Microsoft has made a large mistake in .Net,
which I won't go into now. But my OP was not about that, and the mistake
I see is not in .Net itself in not supporting C++/CLI as a .Net language
as it should be.

At least we know they now know that people use C++ for developing all
aspects of Windows applications in the native code area - let's just
hope they don't forget that!

I am also interested in Windows applications using .Net. Why should that
be slighted ? Microsoft has already had, through MFC which I dislike,
support for C++ Windows applications for over a decade and a half. I am
not interested in going back to that. But evidently Microsoft is
interested in forcing me to use that if I program in C++ or forcing me
to use C# if I move to .Net. That does not explain to me logically why
C++/CLI was created, except as a sop to C++ programmers while forcing
them to use C# instead.

 

[keanep]

.Net is supposed to be language agnostic as long as the language support
the CLR. This is a big part of Microsoft's selling point for it as
opposed to Java.

Since C++/CLI is Microsoft's own C++-like language for .Net they should
support it just as well as they support C# and VB .Net.


If you take a fatalistic attitude that what's done is done and can not
be corrected, then you are right. I do not agree. Technologies are
mutable and can always be changed for the better. Actually in only one
major area do i believe that Microsoft has made a large mistake in .Net,
which I won't go into now. But my OP was not about that, and the mistake
I see is not in .Net itself in not supporting C++/CLI as a .Net language
as it should be.




I am also interested in Windows applications using .Net. Why should that
be slighted ? Microsoft has already had, through MFC which I dislike,
support for C++ Windows applications for over a decade and a half. I am
not interested in going back to that. But evidently Microsoft is
interested in forcing me to use that if I program in C++ or forcing me
to use C# if I move to .Net. That does not explain to me logically why
C++/CLI was created, except as a sop to C++ programmers while forcing
them to use C# instead.

Hi

Although, I can sympathise with the original OP regarding the apparent
re-focus by MS on pushing VC++ for native development, I actually
welcome the acknowledgement that most people view C++ as the tool of
choice for native development, rather than as a .NET tool. The .NET
and Java libraries are very comprehensive frameworks and from my
limited exposure to them, seem quite simple for a developer to get
familiar with (especially when compared to Boost or STL). But, not
all applications can accept the performance hit that comes with
programming to a virtual platform. I'm also not a big fan of MFC,
never have been, I use wxWidgets, but I may re-consider the new-look
MFC.

I would, however, be ***very*** disappointed if MS delay in adding
support for the TR1 extensions to VS2008. Once we have a C++ standard
which includes features such as a threading library, concepts,
reference wrappers and smart pointers, I think C++ will become a
suitable tool for a much broader range of applications, even without a
standard GUI library. I wouldn't be too surprised if we see some C#/
Java applications re-written in native C++, especially where there is
no need to be cross-platform. This is especially applicable in the
area where I work, derivative market-making systems. I'm convinced
there are rich pickings to be made by building a market-making system
in native C++ to exploit the poor performance of the plethora of
trading systems developed by the major banks in C#/Java over the last
few years - I'm actually hoping they keep the C#/Java systems running
just long enough for me to make enough money using my native C++
trading system.

So I wouldn't be too disappointed to see the de-emphasis of C++/CLI,
and consider the opportunities of having a C++ compiler equipped with
the TR1 extensions instead.

Cheers

 

[David Lowndes]

I agree, C++/CLI is a way better language than C# - and I could never

.Net is supposed to be language agnostic as long as the language support
the CLR. This is a big part of Microsoft's selling point for it as
opposed to Java.

It is, but my point was that MS are not an infinite resource and they
saddled themselves with supporting 3 general purpose languages for
..Net. That's more than enough to bog down any organisation.

Since C++/CLI is Microsoft's own C++-like language for .Net they should
support it just as well as they support C# and VB .Net.

I agree - but that won't make it happen

That does not explain to me logically why
C++/CLI was created, except as a sop to C++ programmers while forcing
them to use C# instead.

MS will say that it's there to enable easy (much easier than C# or VB)
interfacing with existing C/C++ code - which it does very well.

Personally, I wish I could do everything .Net in C++/CLI - but I can't
(at least not easily).

Dave

 

[Bo Persson]

Edward Diener wrote:
::
:: Saying that "Microsoft does not care what programming language you
:: use" is absurd. They would certainly care if programmers abandoned
:: C# and VB .Net and switched to C++, Java, Python, or Ruby and did
:: cross-platform or Macintosh or Linux programming instead of
:: Windows programming.

Exactly!

One of the big reasons MS already talks about big improvements in VC10
("Orcas + 1"), is that they have just realized that some people do
high performance server coding in C++. After pushing the .NET thing
for several years, it suddenly occured to them that Windows is no
longer cross-platform enough to run this code. GASP!!


Bo Persson

 

[count0]

... I'm also not a big fan of MFC,
never have been, I use wxWidgets, but I may re-consider the new-look
MFC.

The new (coming) MFC is indeed very attractive to me too, I have be
using WTL
for years.

I would, however, be ***very*** disappointed if MS delay in adding
support for the TR1 extensions to VS2008.

TR1 does not matter so much, boost -- you mentioned -- has (most parts
of) TR1
extension already. So if MS delays TR1 (I heard MS will ship TR1 in
VS2008 sp1 in
next year, right?), we still have option.

My concern is that MS' attitude to C++0x... it seems to me that they are not
very enthusiastic in introducing new features in to C++, comparing to
C#, or
comparing to the early years when there are other big players (like
Borland) in
C++ compiler market.

 

[Edward Diener]

Edward Diener wrote:
::
:: Saying that "Microsoft does not care what programming language you
:: use" is absurd. They would certainly care if programmers abandoned
:: C# and VB .Net and switched to C++, Java, Python, or Ruby and did
:: cross-platform or Macintosh or Linux programming instead of
:: Windows programming.

Exactly!

One of the big reasons MS already talks about big improvements in VC10
("Orcas + 1"), is that they have just realized that some people do
high performance server coding in C++. After pushing the .NET thing
for several years, it suddenly occured to them that Windows is no
longer cross-platform enough to run this code. GASP!!

So they drop ATL Server, there one advanced C++ web server technology ?
That makes no sense given your assumption above.

I just do not buy the idea that Microsoft can not support C++ on both
the native side and the .Net side equally. We are talking about the
richest and most prestigious software company in the world.

 

[Edward Diener]

It is, but my point was that MS are not an infinite resource and they
saddled themselves with supporting 3 general purpose languages for
.Net. That's more than enough to bog down any organisation.

Microsoft is the richest software company in the world, and there are
numberless C++ programmers who would only be too glad to be rated highly
enough by them to work for them. I doubt that they skimped when they
hired Stan Lippman and Herb Sutter to work for them and I doubt, if they
were interested in making C++ a first class .Net language, they would
skimp in hiring top talent to make it so. I am afraid I can not buy this
argument.

I agree - but that won't make it happen

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.

Instead all I have heard is dead silence or needless praise of the fact
that Microsoft has decided to work exclusively on the native C++ side in
VS 2008 and essentially halt and/or remove C++ technologies for .Net in
VS 2008. While I am very happy Microsoft is working more toward standard
C++ compliance, I am very disappointed that they have almost completely
dropped the ball with C++/CLI for .Net.

MS will say that it's there to enable easy (much easier than C# or VB)
interfacing with existing C/C++ code - which it does very well.

Personally, I wish I could do everything .Net in C++/CLI - but I can't
(at least not easily).

There is no basic difference in functionality using C++/CLI interfacing
with .Net as there is using C#. The .Net side of C++/CLI still must
follow CLR and CLS rules. I can not beleieve it is easy/easier
interfacing with C#/VB than with C++/CLI.

 

[David Lowndes]

Microsoft is the richest software company in the world, and there are

numberless C++ programmers who would only be too glad to be rated highly
enough by them to work for them.

That maybe, but we all know that you don't solve software problems by
throwing more people and money at it - it doesn't work! The best
software is made by small groups of people who all know where they're
heading, what they're doing, and are enthusiastic about it. The bigger
a project is, the more bureaucratic and inflexible it will become

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.

Instead all I have heard is dead silence or needless praise of the fact
that Microsoft has decided to work exclusively on the native C++ side in
VS 2008 and essentially halt and/or remove C++ technologies for .Net in
VS 2008. While I am very happy Microsoft is working more toward standard
C++ compliance, I am very disappointed that they have almost completely
dropped the ball with C++/CLI for .Net.

Out of interest, what do you find advantageous in .Net that native C++
doesn't give you?

There is no basic difference in functionality using C++/CLI interfacing
with .Net as there is using C#. The .Net side of C++/CLI still must
follow CLR and CLS rules. I can not beleieve it is easy/easier
interfacing with C#/VB than with C++/CLI.

I don't see why it should be easier either (other than some poor
design decisions - like Win Forms generating code) - but I don't have
to write the tools so I really don't know!

Dave

 

[Larry Smith]

I spent many, many years working in C and then C++ and now I have a couple
of years of C# development under my belt. All of this has been on MSFT
platforms since Bill Gates was still an unknown force. I have no C++/CLI
experience per se so I can't speak to that but I really have to ask, does it
really offer anything that C# doesn't. I realize that's not your point but
seriously, why does anyone need C++ in the .NET world. For good or bad, C#
was invented from the ground up for that environment and it's a natural fit.
Unless there's something I don't know, I fail to see what's so important
about C++ here. When you work in .NET, you're mostly working with the
framework so IMO it's normally a bad idea to drag in foreign baggage like
C++ collections, templates, or even various constructs (if they stray too
far from the .NET way of doing things). You'ld then be supporting two
platforms effectively, the native .NET stuff and the native C++ stuff. For
most projects this will only create a lot of additional problems. You'ld
therefore be better off stripping out most of the native C++ stuff but by
the time you do that you're mostly left with raw C++ syntax only. The
benefits and advantages of C++ are then mostly gone so you might as well
just rely on C#/. If you think I'm a fan of all this however, understand
that I think C# was a big mistake in the first place and C++ should have
been used from the outset. C++ is a mature and well-established language and
even with the necessary extensions to make it work for .NET, there was no
need to turn tens or evens hundreds of thousands of experienced C++
developers into novices all over again (which hurts MSFT as well IMO but
that's another story). What's done is done however and you'll have to live
with it as we all do.

 

[David Lowndes]

I have no C++/CLI

experience per se so I can't speak to that but I really have to ask, does it
really offer anything that C# doesn't.

If you've been using C# for 2 years, you'll presumably be familiar
with "using" - so that's one thing C++/CLI doesn't need, and more
importantly there's no need to guess when you ought to use "using".

And of course, it has seamless access to native C/C++ code.

For good or bad, C#
was invented from the ground up for that environment and it's a natural fit.

But even now there are some OS facilities that aren't accessible from
managed code.

You'ld
therefore be better off stripping out most of the native C++ stuff but by
the time you do that you're mostly left with raw C++ syntax only.

Some companies have millions of lines of tested C/C++ code, they
aren't going to throw that away - ever (until it's of no use to them).

If you think I'm a fan of all this however, understand
that I think C# was a big mistake in the first place and C++ should have
been used from the outset.

An ally to the cause after all

Dave

 

[Edward Diener]

That maybe, but we all know that you don't solve software problems by
throwing more people and money at it - it doesn't work! The best
software is made by small groups of people who all know where they're
heading, what they're doing, and are enthusiastic about it. The bigger
a project is, the more bureaucratic and inflexible it will become

I obviously was not talking about more people but about the quality of
the programmer. My point is that Microsoft can afford to hire really
excellent people, and pay them very well, if they want.

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. Borland's OWL was better and
Borland's VCL much better. The latter, with C++ Builder, is a RAD visual
programming environment. Microsoft hired the leading VCL designer,
Hejlsberg, to make .Net an even better RAD visual programming
environment and he succeeded magnificently. Of course he immediately
caught Microsoft-induced amnesia and declared that .Net was the first

Out of interest, what do you find advantageous in .Net that native C++
doesn't give you?

..Net gives me a Visual RAD programming environment of components with
properties, methods, and events that is easy to use. I can drop both
visual and non-visual components on a form, or instantiate them at
run-time in code, and the components will work exactly the same. I can
build up my application with those components and I can write the
components myself if I need to.

Of course if C++ programmers think that MFC's macros are events and
their declspec(property(...)) are properties, and their GUI classes are
components, then they should stick to that.

 

[Edward Diener]

I spent many, many years working in C and then C++ and now I have a couple
of years of C# development under my belt. All of this has been on MSFT
platforms since Bill Gates was still an unknown force. I have no C++/CLI
experience per se so I can't speak to that but I really have to ask, does it
really offer anything that C# doesn't.

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.

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

I realize that's not your point but
seriously, why does anyone need C++ in the .NET world. For good or bad, C#
was invented from the ground up for that environment and it's a natural fit.
Unless there's something I don't know, I fail to see what's so important
about C++ here. When you work in .NET, you're mostly working with the
framework so IMO it's normally a bad idea to drag in foreign baggage like
C++ collections, templates, or even various constructs (if they stray too
far from the .NET way of doing things). You'ld then be supporting two
platforms effectively, the native .NET stuff and the native C++ stuff. For
most projects this will only create a lot of additional problems. You'ld
therefore be better off stripping out most of the native C++ stuff but by
the time you do that you're mostly left with raw C++ syntax only. The
benefits and advantages of C++ are then mostly gone so you might as well
just rely on C#/.

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

If you think I'm a fan of all this however, understand
that I think C# was a big mistake in the first place and C++ should have
been used from the outset. C++ is a mature and well-established language and
even with the necessary extensions to make it work for .NET, there was no
need to turn tens or evens hundreds of thousands of experienced C++
developers into novices all over again (which hurts MSFT as well IMO but
that's another story). What's done is done however and you'll have to live
with it as we all do.

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

 

[Larry Smith]

I have no C++/CLI

If you've been using C# for 2 years, you'll presumably be familiar
with "using" - so that's one thing C++/CLI doesn't need, and more
importantly there's no need to guess when you ought to use "using".

I assume you're referring to the using "statement" for cleaning up resources
via "IDisposable" opposed to the using "directive" for eliminating the
explicit use of namespaces (or for creating aliases). 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. Sometimes there is but I think
it's more the fault of the .NET docs which are very weak IMO. I do agree
that it's ugly compared to a C++ destructor however (if this is what you're
alluding to) and have even argued that in past (in the C# NG). I'm sure
C++/CLI has its own warts however and it's certainly no reason to pick
C++/CLI over C#.

And of course, it has seamless access to native C/C++ code.

Also a trivial issue for most applications IMO but I agree that it is a
problem. This has nothing to do with C# however. The .NET framework simply
hasn't closed the gap but it will probably narrow it in time. Of course it
never could completely close the gap and hope to remain platform neutral.
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.

But even now there are some OS facilities that aren't accessible from
managed code.

Agreed as previously noted.

Some companies have millions of lines of tested C/C++ code, they
aren't going to throw that away - ever (until it's of no use to them).

That's a very good point but I seriously doubt a lot of companies are
migrating mega-applications like this. More likely they're trying to
leverage old C++ code in newer .NET apps. In any case it's really by
necessity and not based on technical merit. If you're starting a new
application from scratch then I stick by my original post.

An ally to the cause after all

I don't like it but the cause is now lost. While I'll be returning to my C++
roots eventually, I believe the language is in permanent decline on Windows.
On the bright side it means more $ down the road for vets like myself (what
are COBOL programmers now making) so do I now qualify as a traitor?

 

[David Lowndes]

Out of interest, what do you find advantageous in .Net that native C++

.Net gives me a Visual RAD programming environment of components with
properties, methods, and events that is easy to use. I can drop both
visual and non-visual components on a form, or instantiate them at
run-time in code, and the components will work exactly the same. I can
build up my application with those components and I can write the
components myself if I need to.

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.

Dave