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. 53 2287
"Edward Diener" <ed*******************@tropicsoft.comwrote in message
news:OU*************@TK2MSFTNGP04.phx.gbl...
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.
Tom Walker wrote:
"Edward Diener" <ed*******************@tropicsoft.comwrote in message
news:OU*************@TK2MSFTNGP04.phx.gbl...
>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.
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.
>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
"Edward Diener" <ed*******************@tropicsoft.comwrote in message
news:uH**************@TK2MSFTNGP04.phx.gbl...
>
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.
>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.
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
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
Bo Persson wrote:
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.
David Lowndes wrote:
>>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.
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.
>
>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 :)
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.
>
>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).
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.
>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
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.
>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
David Lowndes wrote:
>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 :(
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.
>
>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. 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
RAD visual programming environment etc. <g>
>
>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?
..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.
Larry Smith wrote:
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."
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".
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.
>>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.
Agreed as previously noted.
>>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).
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.
>>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 :)
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?
>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.
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
"David Lowndes" <Da****@example.invalidwrote in message
news:15********************************@4ax.com...
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
>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?
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
"David Lowndes" <Da****@example.invalidwrote in message
news:86********************************@4ax.com...
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
"Larry Smith" <no_spam@_nospam.comwrote in message
news:uN**************@TK2MSFTNGP03.phx.gbl...
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
"Edward Diener" <ed*******************@tropicsoft.comwrote in message
news:uC*************@TK2MSFTNGP04.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
"Edward Diener" <ed*******************@tropicsoft.comwrote in message
news:O%****************@TK2MSFTNGP06.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
>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
John Carson wrote:
"Edward Diener" <ed*******************@tropicsoft.comwrote in message
news:uC*************@TK2MSFTNGP04.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.
>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'?
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.
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.
"Edward Diener" <ed*******************@tropicsoft.comwrote in message
news:uH**************@TK2MSFTNGP04.phx.gbl...
Tom Walker wrote:
>"Edward Diener" <ed*******************@tropicsoft.comwrote in message news:OU*************@TK2MSFTNGP04.phx.gbl...
>>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.
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.
"Edward Diener" <ed*******************@tropicsoft.comwrote in message
news:%2****************@TK2MSFTNGP03.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
"Edward Diener" <ed*******************@tropicsoft.comwrote in message
news:e1**************@TK2MSFTNGP03.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 Lowndes" <Da****@example.invalidwrote in message
news:ur********************************@4ax.com...
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
"Larry Smith" <no_spam@_nospam.comwrote in message
news:ub**************@TK2MSFTNGP03.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
"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message
news:uS**************@TK2MSFTNGP05.phx.gbl...
>
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
>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).... ;)
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.
Ben Voigt [C++ MVP] wrote:
"Edward Diener" <ed*******************@tropicsoft.comwrote in message
news:uH**************@TK2MSFTNGP04.phx.gbl...
>Tom Walker wrote:
>>"Edward Diener" <ed*******************@tropicsoft.comwrote in message news:OU*************@TK2MSFTNGP04.phx.gbl... 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.
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.
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" <ed*******************@tropicsoft.comwrote in message
news:ua**************@TK2MSFTNGP03.phx.gbl...
Ben Voigt [C++ MVP] wrote:
>"Edward Diener" <ed*******************@tropicsoft.comwrote in message news:uH**************@TK2MSFTNGP04.phx.gbl...
>>Tom Walker wrote: "Edward Diener" <ed*******************@tropicsoft.comwrote in message news:OU*************@TK2MSFTNGP04.phx.gbl... 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.
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.
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 /clr:pure) 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.
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.
>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.
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.
"Larry Smith" <no_spam@_nospam.comwrote in message
news:eI**************@TK2MSFTNGP05.phx.gbl...
>>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.
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.
I respectfully disagree. It's quite useful to have tailored languages to
particular tasks, as long as the integration effort is low. Just because a
program needs to call some library that must be implemented with assembly
language (like Interlocked* functions), should the entire program be forced
into assembler? Of course not. regexes in C++ are ugly, much better to
use perl for that. Child process automation in C++ is ugly, much better to
use tcl/expect for that.
C++/CLI is a quantum leap forward in this respect because it exposes the
native power of raw C and assembler to a managed environment, and it does so
*easily*. Compare the effort needed to make a .NET component in C++/CLI vs
creating a Java JNI, TCL extension, Perl binary module, etc in C or C++.
I've heard Lua and Ruby are the other high level language that integrates
very well with C, and I doubt even they make it as trivial as C++/CLI.
For example:
void asmbreak( void )
{
__asm int 3;
}
public ref class Fragile
{
public:
static void BreakMe() { asmbreak(); }
};
What's that, under 30 tokens (not counting the assembly itself) to make any
assembler code available to a C# or VB.NET or JS.NET or F# or Eiffel.NET
program?
It's quite useful to have tailored languages to particular tasks, as long
as the integration effort is low
Integration is a secondary concern. The complexity of supporting two large
and complicated languages like C# and C++ is your main concern. Now you need
expertise on your staff not only in two languages, but two platforms
(managed and unmanaged). This creates serious problems on various fronts.
One language, one platform. Life is now so much more simple. If the gaps
were closed between .NET and the WinAPI then this could be a reality. You
would then need to turn to another language/platform only when necessity
truly demands it. In practice that would almost be never (for most
organizations anyway).
>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.
There'd be less of a tie in because it would have to interface
seamlessly with standard C/C++ code - like C++/CLI does :)
>So locking us into a proprietary environment alone does not explain why they pushed managed.
It won't be the whole story, there will be grains of truth in all
arguments we get to hear - and the ones we don't hear.
Merry Christmas
Dave
>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.
That assumes that MS listen to all their customers - they've recently
discovered (with the renewed interest in native VC++) that they
haven't been listening to all their customers... though I suspect the
situation is more that they haven't *heard* from all their customers!
The segment of their customers who use native C++ probably don't
attend the marketing shindigs (TechEd/MSDN events) that's the normal
capture for those gigs.
Merry Christmas
Dave
>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.
I think the easiest solution would be to pull the warning that the
static code analysis gives into the C# compiler so we see it for a
normal compile pass. That may give it a squiggle automatically?
Would anyone want to vote on that (if it's not already filed on
connect)?
Dave
>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).
All this misses the simple fact that some developers (most likely the
target audience for C#) don't know about the using statement (or the
issue it solves).
I've been working on a mixed C# C++/CLI project for the last year and
have had to educate my colleagues to its existence despite being the
last man in on the C# code. Consequently we have loads of code that
probably ought to have using statements - but doesn't.
>The issue of "IDisposable" is nevertheless a very tiny one in the grand scheme of things.
I think it's actually quite a fundamental issue that the language has
such an unintuitive hole in it.
>... C++ should have been used in the first place.
We agree on that :)
Merry Christmas
Dave
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.
That seems to be wrong. You and I couldn't figure out how to do it, but
someone did, and some of my C# code has been a client of it.
"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message
news:uH**************@TK2MSFTNGP05.phx.gbl...
>
"Edward Diener" <ed*******************@tropicsoft.comwrote in message
news:ua**************@TK2MSFTNGP03.phx.gbl...
>Ben Voigt [C++ MVP] wrote:
>>"Edward Diener" <ed*******************@tropicsoft.comwrote in message news:uH**************@TK2MSFTNGP04.phx.gbl... Tom Walker wrote: "Edward Diener" <ed*******************@tropicsoft.comwrote in message news:OU*************@TK2MSFTNGP04.phx.gbl... >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. > 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.
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 /clr:pure) 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.
>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.
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.
I do. (Pedant's corner: I read it not heard it.)
I also remember when Visual Studio 2005 broke that promise in Windows Mobile
projects.
"Tom Walker" <no****@nowhere.comwrote in message
news:%2****************@TK2MSFTNGP03.phx.gbl...
"Edward Diener" <ed*******************@tropicsoft.comwrote in message
news:uH**************@TK2MSFTNGP04.phx.gbl...
>> 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.
"Norman Diamond" <nd******@community.nospamwrote in message
news:Ot**************@TK2MSFTNGP04.phx.gbl...
>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.
That seems to be wrong. You and I couldn't figure out how to do it, but
someone did, and some of my C# code has been a client of it.
Ok, it might be possible, but it must be relying heavily on undefined
behavior and reverse engineering the C++ compiler. It's not a good idea,
and is prone to break at any time, such as following some Windows Update.
Even C++ cannot safely use a C++ library in a separate DLL without using a
framework such as COM.
>
"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message
news:uH**************@TK2MSFTNGP05.phx.gbl...
>> "Edward Diener" <ed*******************@tropicsoft.comwrote in message news:ua**************@TK2MSFTNGP03.phx.gbl...
>>Ben Voigt [C++ MVP] wrote: "Edward Diener" <ed*******************@tropicsoft.comwrote in message news:uH**************@TK2MSFTNGP04.phx.gbl... Tom Walker wrote: >"Edward Diener" <ed*******************@tropicsoft.comwrote in >message news:OU*************@TK2MSFTNGP04.phx.gbl... >>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. >> 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.
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 /clr:pure) 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.
>>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.
"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message
news:uo**************@TK2MSFTNGP05.phx.gbl...
>
Even C++ cannot safely use a C++ library in a separate DLL without using a
framework such as COM.
I had thought that if the C++ DLL exported abstract class interfaces, then
it was version and compiler independent. See http://groups.google.com/group/micro...593fb779fd1acb
for further thoughts. If something like this will not work, I'd be
interesting in discussing it.
Thanks,
David
"David Ching" <dc@remove-this.dcsoft.comwrote in message
news:dI******************@newssvr21.news.prodigy.n et...
"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message
news:uo**************@TK2MSFTNGP05.phx.gbl...
>> Even C++ cannot safely use a C++ library in a separate DLL without using a framework such as COM.
I had thought that if the C++ DLL exported abstract class interfaces, then
it was version and compiler independent. See
It is if it is done consistently and memory ownership rules are also
followed. That's what I meant by a framework similar to COM. http://groups.google.com/group/micro...593fb779fd1acb
for further thoughts. If something like this will not work, I'd be
interesting in discussing it.
Thanks,
David
"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message
news:ug**************@TK2MSFTNGP03.phx.gbl...
>
It is if it is done consistently and memory ownership rules are also
followed. That's what I meant by a framework similar to COM.
Sounds good, thanks.
-- David
"David Ching" <dc@remove-this.dcsoft.comwrote in message
news:dI******************@newssvr21.news.prodigy.n et...
"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message
news:uo**************@TK2MSFTNGP05.phx.gbl...
>> Even C++ cannot safely use a C++ library in a separate DLL without using a framework such as COM.
I had thought that if the C++ DLL exported abstract class interfaces, then
it was version and compiler independent. See http://groups.google.com/group/micro...593fb779fd1acb
for further thoughts. If something like this will not work, I'd be
interesting in discussing it.
I see no mention of version and compiler independence in the message that
you cited. If there were then it would surely be wrong.
There is no requirement for two compilers to agree on the length of a long.
There is no requirement for two compilers to agree on the representation of
negative numbers (one could use one's complement and one could use two's
complement) though of course for performance reasons most sensible compilers
for a single platform will agree on that. Two versions of a single compiler
might disagree on whether wchar_t is a separate type or just a typedef for
one of the integral types.
In P/Invoke, the caller's coder has to specify types that will map onto the
same number of bits and endianness and everything that the callee is going
to expect. But I didn't think this would depend on whether COM is being
used or not.
On Dec 22, 8:42*am, Edward Diener
<eddielee_no_spam_h...@tropicsoft.comwrote:
Why bother having Stan Lippman and Herb Sutter created aC++/CLI
language for .Net development when Microsoft, and the VC++ development
team, are so clearly intent on limiting .Net development withC++/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 withC++/CLI, since
it serves little to no purpose forC++programmers anymore. Here is the
lineup:
1)ASP .NET, not forC++
2) Web services in .Net, not forC++and even web services client
development is removed in VS 2008.
3) WPF, not forC++and even creating controls for WPF is absent forC++/CLI.
4) WCF, not forC++.
5) WWF, not forC++
6) LINQ, not forC++.
Finally all advanced web application development is remove fromC++with
the abandonment of the ATL Server.
VS 2008 is an abortion forC++.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 inC++, 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 forC++
developers to effectively compete with C# developers in the .Net world.
It was just a sop so that they could attractC++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.
Try C++ Builder 2007. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Homer |
last post by:
Hi All,
In my work place we are still using VS6.00 with C++ and are not
allowed to use a newer version (to connect to source control). We also
use ClearCase as source control software.
What I...
|
by: =?Utf-8?B?RGlwZXNoX1NoYXJtYQ==?= |
last post by:
Hi all,
I am porting an code written in VC++ to VC.Net to make it manage. But in
Managed VC we dont use "const" keyboard at all. but my code is using it very
frequently, so is their any...
|
by: =?Utf-8?B?UmFqZXNoYXowOQ==?= |
last post by:
I heared that microsoft give technical support to vb upto this year end. Can
any one microsoft stops techinical support for vc++(6.0)? was microsoft
announced any official date?
|
by: =?Utf-8?B?S3VlaXNoaW9uZyBUdQ==?= |
last post by:
What is the difference between the regular VC++ edition and the VC++ express
edition? If there is not too much difference in functionality, why the
express edition
is free?
|
by: Iouri |
last post by:
Hi everybody,
We are currently using VS2003 and now we are in the porcess of upgrading to
the next Visual Studio version. Does somebody have a real life experience
with VS2008?
My boss wants to...
|
by: Academia |
last post by:
I have vs2005 installed on the System disk and vs2008 installed on a
different disk.
I want to remove VS2005. I read one time about some problem with
uninstalling vs2005 after vs2008 is...
|
by: goo.one1 |
last post by:
Hi All,
I'm looking for info on how to port VC++ 6 code/projects to VC++ 9
(2008).
I noticed that there is a converter built-in for Visual *BASIC* to
convert from VS6 to 9...
I have found...
|
by: =?Utf-8?B?S3VlaXNoaW9uZyBUdQ==?= |
last post by:
I want to create a sound to alert the user when some event occurs.
How do I do it from my VC++ .NET window form program?
|
by: =?Utf-8?B?SmFtZXMgV29uZw==?= |
last post by:
Hi everybody,
There is a fatal error while installing VS2008 SP1 on Vista 64bit Business
edition. The last line of error log is
Installation failed with error code: (0x80070643)
I tried to...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |