Re: Rumors of reduced support for C++ /CLI
"Edward Diener" <email@example.com> wrote in message
Ben Voigt [C++ MVP] wrote:
Microsoft sold a lie to C++ programmers wanting to use it for .Net
applications, saying it would be a first class language on par with C#
and VB .Net. Language-wise it is better than C# but support-wise it is
far worse, and therefore largely unusable for the latest .Net
technologies. It's wonderful glue to the native Windows world, and one
can still create components, Windows form derived controls with it, as
well as Windows form and console applications, but that is about it.
For the latest .Net technologies, and ASP .Net, one needs C#, and I
maintain that this was Microsoft's intention from the very start in
order to rope C++ programmers to use C#.
Well, you can use all these technologies from C++/CLI. Just not
In other words I can't use VS's visual tools with these technologies and
C++/CLI. How lucky can I be !
I'm more saddened by the state of the third-party addins at this point.
The C++ "visual tools" have always been atrocious. ClassWizard? I never
used that piece of trash even in VC6, I don't understand why everyone is
begging to bring it back/speed it up/whatever. If I want to add a member
variable to a class I'd rather type "typename variablename;" into the
section of the header file where it logically belongs than put "typename"
and "variablename" into two boxes in a dialog and have it added at the
How noble you are doing all your visual coding at the lowest level. Give
that man a toga with royal purple on it.
Well, that wasn't "visual coding". That's really basic coding which IMHO is
much better done with source code than wizards.
On the other hand, GUI layout is much better with visual tools. And the
ones for C++ work -- really well in my experience. Dialog Editor (for
native code) works fine. Microsoft doesn't ship a WinForms editor which
works with C++/CLI, but they do ship all the support code to make it, maybe
not easy, but straightforward, for a third-party to do so. With WPF it
should be even easier because the editors export XAML which is XML-based so
it is *very* easy to process programmatically. Writing a program to consume
XAML and create matching C++/CLI header files just wouldn't be that hard, so
if anyone wanted it I think it would have been done already.
XAML isn't supported in the C++/CLI compiler, but you can call WPF
I am overjoyed !
Considering how easy it is to generate code from a XAML description, this
should be a non-issue.
It isn't a non-issue because support for code-behind exists in C# and VB
.Net. Whether it is XAML or ASP .Net markings, or the latest .Net
technologies, C++/CLI programmers shouldn't have to figure it out for
themselves and forgo visual tools. The whole point of a visual programming
environment is to make programming easier. Saying that X and Y is easy and
a non-issue is nonsense. If it were so easy you should dispense with VS
Studio completely and just use and editor and command-line tools. Have you
done that ? Why not ?
I write just as much C++ code using vim as Visual Studio.
Historically third-parties have been much better at providing wizards
for C++ than Microsoft, so it's not really a big loss.
You have got to be kidding !
Not in the least. Anyone who has ever used Visual Assist X from
WholeTomato will agree. It doesn't matter how broken Microsoft's
Intellisense is, because someone else fixed it.
Who gives a xxxx about Intellisense. I am talking about using core visual
programming support which Microsoft supplies in VS Studio for C# and does
not for C++/CLI. Stop pretending that none of this matters.
If you don't find Intellisense more important than WPF interactive layout,
then I think you're a designer not a programmer.
And if you aren't comfortable working with the source code, then perhaps you
ought to be using a language like C# or Java which is "safe" by default
(note safe does not mean correct) rather than C++.
None of the "visual tools" people are moaning about not having support
for C++/CLI are more than a very thin wrapper around the .NET BCL. It
wouldn't take these professional plugin developers more than a couple
weeks at most to make a superior version for C++/CLI. But they haven't,
which suggests that the people who want to use C++/CLI for a WPF GUI, or
for ASP.NET development, are a very small minority. If you disagree with
their assessment of the market size, why not build such a plugin. If
people want that, they'll pay $75/seat. If there aren't enough consumers
to make that profitable, then Microsoft has also made the right decision
to put their resources elsewhere.
They haven't because it does not take a couple of weeks, and because
Microsoft has repeatedly done their best to move all C++ programmers
programming .Net to C#. Then they ( and you ) say that it is the C++
programmers who don't want to use .Net but native C++ instead. What utter
falseness ! But since you are a support person for them, of course you
must follow the party line.
Nope. I'm not a support person for Microsoft. I'm not employed by them.
And the benefits I get as an MVP are not linked to saying good things about
them in any way, they explicitly encourage MVPs to speak openly and
honestly. Sure, I'll send negative comments to them first and give them a
chance to correct things before making the negative statements public, but
I'd do that for any software company.
And if you think C++ developers avoid .NET only because of poor tool support
you are very much mistaken. There are a lot of applications where native
C++ does better than C++/CLI -- fast startup, lower memory usage, no pauses
for GC, portability, etc, etc. All the "visual tools" in the world won't
make these projects move to C++/CLI.
The truth remains is that MS never intended to support .Net programming
with C++, and they have done a consistently abysmal job at it, no doubt
encouraged in their mediocrity by directives from on high. They want to
sell C# for .Net programming, and they never intended to support C++ for
.Net programming except in the most minimalistic way.
You've clearly made up your mind to think that, so don't let facts get in
But you haven't answered the argument that the number of potential users of
such tools do not justify the programming effort. Whether it takes a couple
hours or a couple man-years doesn't matter, if the economics are right then
a third-party will step up, and if they aren't then why do you expect
Microsoft to throw away money?