.NET Framework - Disappointment in VC++ .Net in VS2008

Asked By Edward Diener

22-Dec-07 11:42 AM

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.

22-Dec-07 02:29 PM

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.

22-Dec-07 05:17 PM

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.

22-Dec-07 07:41 PM

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

22-Dec-07 07:51 PM

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.

22-Dec-07 09:06 PM

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.


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.

22-Dec-07 09:20 PM

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

24-Dec-07 07:56 AM

On Dec 23, 10:20=A0am, Edward Diener
t


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

23-Dec-07 05:01 AM

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.


I agree - but that won't make it happen :)


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

23-Dec-07 06:31 AM

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

23-Dec-07 08:52 AM

[...]

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


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.

23-Dec-07 09:12 AM

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.

23-Dec-07 09:18 AM

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.


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.


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.

23-Dec-07 12:33 PM

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 :(


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


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


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

23-Dec-07 01:05 PM

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.

23-Dec-07 03:09 PM

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.


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


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


An ally to the cause after all :)

Dave

23-Dec-07 03:11 PM

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.


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>


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

23-Dec-07 03:26 PM

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 do not agree at all with your idea that adding native C++ to .Net
programming creates additional problems.


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

23-Dec-07 04:11 PM

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


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.


Agreed as previously noted.


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.


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?

23-Dec-07 05:17 PM

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

23-Dec-07 05:36 PM

Yes that's what I meant.


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


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


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


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

Dave

23-Dec-07 06:11 PM

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

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

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

-- David

23-Dec-07 06:17 PM

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

23-Dec-07 06:57 PM

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

23-Dec-07 07:18 PM

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

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

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

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

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

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

23-Dec-07 07:56 PM

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

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

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


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

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


And the reason is ?


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

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

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

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

23-Dec-07 09:14 PM

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


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


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

23-Dec-07 09:20 PM

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




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



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



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



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

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



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

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



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



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

-- David

23-Dec-07 09:22 PM

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

23-Dec-07 09:46 PM

If Microsoft had did what Borland had done and just made a RAD environment
in C++ but entirely native code, then that would be worth preserving.  As it
is, they did it in C++ but made it dependent on .NET, which has its own
issues with performance and deployability.  As it is, the minor improvements
that C++/CLI has over C# (significant improvements, especially if you
already know C++, no doubt, but minor compared to them not making it native
code) do not make it worth perserving, as a first class Visual RAD language,
IMHO.

-- David

23-Dec-07 09:55 PM

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

23-Dec-07 10:17 PM

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

23-Dec-07 10:25 PM

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.


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


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

23-Dec-07 10:38 PM

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



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



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

23-Dec-07 10:49 PM

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


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


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


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


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


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

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


See above for why all this is so.

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


You argue the party line very well.


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

24-Dec-07 12:35 AM

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


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

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


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

john carson

24-Dec-07 04:48 AM

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

24-Dec-07 04:58 AM

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

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


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


I agree entirely.

Merry Christmas
Dave

24-Dec-07 07:46 AM

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.

24-Dec-07 07:59 AM

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
really only applies to objects holding unmanaged resources and it's no
reason to choose C++ over C#.


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


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

24-Dec-07 08:04 AM

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

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

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

24-Dec-07 08:30 AM

Larry,

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


Why ever would you want to do that?


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

Merry Christmas
Dave

24-Dec-07 08:39 AM

I hear you and agree on that point.


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


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


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


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

When I bring that up I just

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

24-Dec-07 09:28 AM

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


interface ISomeInterface
{
// ...
}

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

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

This won't compile without the "as IDisposable" as seen. It's safe though if
returned in the "using" statement (which is tested for in the underlying
to C++.


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

24-Dec-07 10:10 AM

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.

24-Dec-07 11:10 AM

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.

24-Dec-07 11:12 AM

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.



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

-- David

24-Dec-07 11:12 AM

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

24-Dec-07 11:12 AM

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

24-Dec-07 11:12 AM

You think it's not an issue for us lazy programmers used to Intellisense to
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

24-Dec-07 11:15 AM

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

24-Dec-07 11:28 AM

They aren't competing, they are complementary.

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


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

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

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

24-Dec-07 11:36 AM

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.

24-Dec-07 12:02 PM

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.


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


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

24-Dec-07 12:29 PM

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.

24-Dec-07 12:53 PM

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

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

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

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

24-Dec-07 01:08 PM

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.



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

24-Dec-07 01:11 PM

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

24-Dec-07 01:13 PM

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.


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

24-Dec-07 01:24 PM

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.

24-Dec-07 01:56 PM

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?

24-Dec-07 02:16 PM

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

24-Dec-07 04:15 PM

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

24-Dec-07 04:20 PM

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

24-Dec-07 04:35 PM

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.


I think it's actually quite a fundamental issue that the language has
such an unintuitive hole in it.


We agree on that :)

Merry Christmas
Dave

24-Dec-07 05:44 PM

Whether you use C++/CLI, with it's better destructor semantics or C#
with its IDisposable.Dispose(), .Net and other purely GC languages have
the fundamental flaw that the release of non-memory resources has to be
handled manually.

The "using" statement is a neat shortcut only when an object of an RAII
class is used locally and then destroyed, releasing its resource(s). If
that object needs to be passed around so that the last reference to the
object which is destroyed releases the resource, there is no solution in
.Net ( and other pure GC languages ) other than "don't do that because
if you do you will have to invent some means of keeping track of the
object's references yourself." As you may well know in native C++, which
is not a GC language, boost::shared_ptr<T> will do exactly that for you,
as well as releasing the memory of the object.

However all this has little to do with my OP, althoug I do undertsand
how the discussion started.

Nonetheless I thank all people who have responded. Perhaps if C++
programmers had been more indignant in their interactions with Microsoft
and the VC++ team, the history of C++/CLI and its reduction to a second
class language would not have happened.

However I continue to believe that it did happen not largely for
technical reasons but because Microsoft's need to rope C++ programmers
in to using their own language, C#, was far more important to them and
their business than the honest competition between two similar but
different technologies.

24-Dec-07 07:57 PM

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.

24-Dec-07 07:57 PM

That seems to be wrong.  You and I could not figure out how to do it, but
someone did, and some of my C# code has been a client of it.

26-Dec-07 10:01 AM

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.

26-Dec-07 02:12 PM

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/microsoft.public.vc.mfc/msg/52593fb779fd1acb
for further thoughts.  If something like this will not work, I'd be
interesting in discussing it.

Thanks,
David

26-Dec-07 03:21 PM

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.

26-Dec-07 03:40 PM

Sounds good, thanks.

-- David

26-Dec-07 07:33 PM

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.

27-Dec-07 05:28 AM

Try C++ Builder 2007.

26-Dec-07 10:26 PM

By using abstract interface classes, memory management issues are avoided
(as no data is specified).  Because the only memory is the class's v-table
which is a 4 byte pointer in C compilers (all the ones that matter, anyway).
Of course, there are data types in params to the interface methods which
need to be compatible, but with Windows compilers, these are pretty standard
anyway.  I haven't had a problem with this scheme with different versions of
VC++, but I'm not sure about compatibility with something like GNU.  I
imagine Borland compilers would be OK too.

-- David

27-Dec-07 03:02 AM

It is a fact that, as of now, .Net programming is little used by Independent
Software Vendors (ISVs), which overwhelmingly use native code. "Legacy"
applications include almost all of the major desktop applications and
Windows itself. Native will continue to dominate these spaces for some years
to come. Not all of these applications use MFC, but a lot do.

john carson

27-Dec-07 04:41 PM

As long as a C++ compiler supports COM, it is guaranteed that abstract
virtual methods will work. On non-Microsoft platforms, however, there
are no guarantees regarding v-table compatibility.

With Borland compilers the most important compatibility issue is with
enum (it defaults to 8-bit in C++Builder, while it is int-sized in VC++).

Tom

27-Dec-07 05:45 PM

On many (most?) non-Microsoft platforms, there is an ABI specification
(application binary interface) providing much better guarantees regarding
compatibility.