 |
|
| .NET DotNet Forum Index » Visual C++ Forum » Rumors of reduced support for C++ /CLI... |
|
Page 2 of 2 Goto page Previous 1, 2 |
|
| Author |
Message |
| Ben Voigt [C++ MVP]... |
 Posted: Mon Aug 24, 2009 10:06 am |
|
|
|
Guest
|
Quote: 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
code-mixed-with-the-markup.
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 end.
Quote:
XAML isn't supported in the C++/CLI compiler, but you can call WPF APIs.
I am overjoyed !
Considering how easy it is to generate code from a XAML description, this
should be a non-issue.
Quote: 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.
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. |
|
|
| Back to top |
|
|
|
| Ben Voigt [C++ MVP]... |
| Posted: Mon Aug 24, 2009 10:10 am |
|
|
|
Guest
|
The triage bar means that they're close to releasing a product and don't
want to risk breaking existing code in order to fix your bugs. One of the
bugs I posted was a regression on code that used to compile in VS2005 and it
got fixed _FAST_.
The moment they announce VS2010 going RTM, you should reopen every single
bug closed with that reason.
I don't know why they can't mark it with a milestone "post VS2010" instead
of closing the issue. Seems stupid to me, every major bug tracking system
in the world, including Microsoft's own Team Foundation Server, supports the
milestone concept. |
|
|
| Back to top |
|
|
|
| Edward Diener... |
| Posted: Mon Aug 24, 2009 10:31 am |
|
|
|
Guest
|
Ben Voigt [C++ MVP] wrote:
This is bull. I have reported bugs very soon after a new release has
occurred and they always get the "triage remark". As I said the C++/CLI
Microsoft developers simply do not want to fix bugs, period, and the
"triage" remark, or whatever phony Microsoft-speak is invented next, is
just their coverup of that. |
|
|
| Back to top |
|
|
|
| Brian Muth... |
| Posted: Mon Aug 24, 2009 1:19 pm |
|
|
|
Guest
|
"Edward Diener" <eddielee_no_spam_here at (no spam) tropicsoft.com> wrote in message
news:eHnu1d2IKHA.6068 at (no spam) TK2MSFTNGP03.phx.gbl...
Quote: Brian Muth wrote:
Nonetheless Microsoft's abysmal support for C++/CLI, along with their
almost complete refusal to fix C++/CLI bugs ...
What bugs are you referring to? I've always considered C++/CLI to be
extremely stable.
Here are bug report numbers:
101670
not found
101671
not found
101674
not found
101677
workaround provided
101678
not found
192619
not found
199186
not found
205446
not found
216882
not found
249881
not found
275035
not found
295385
not found
344776
not found
362782
not found
431084
not found
any others that I can review?
Quote: What is most amusing is that you equate C++/CLI stability as an indicator
of good support. I, OTOH, consider good support the ability to implement
features and to fix bugs.
I've been very favourably impressed by Microsoft's commitment to
enhancements, new features, and bug fixes. One only needs to see the new
feature list of Visual Studio 2010 to see this.
Brian |
|
|
| Back to top |
|
|
|
| Ben Voigt [C++ MVP]... |
| Posted: Mon Aug 24, 2009 1:19 pm |
|
|
|
Guest
|
"Edward Diener" <eddielee_no_spam_here at (no spam) tropicsoft.com> wrote in message
news:#ZgV5hNJKHA.4432 at (no spam) TK2MSFTNGP05.phx.gbl...
You didn't quote the part of my email where I agreed that *closing* bug
reports based on the triage bar is pure stupidity.
But do you have an example of a bug (not feature request) which was closed
by triage early in the product cycle? If so I will use that to prove to the
developers that their triage system is broken. |
|
|
| Back to top |
|
|
|
| Brian Muth... |
| Posted: Mon Aug 24, 2009 3:18 pm |
|
|
|
Guest
|
Thanks, Ben. I was curious to see what the list consisted of. Having put out
a commercial product ourselves I've become acutely aware of the fact that
some bugs simply don't warrant the effort of complete eradication because
they simply are innocuous, have trivial workarounds, or are simply
inconsequential. And we also will find that some bugs require design changes
that are best dealt with by deferring to the next version. I've never
reviewed the bugs at connect.microsoft.com so I was curious what categories
they fall into, in my judgement.
Brian |
|
|
| Back to top |
|
|
|
| Edward Diener... |
| Posted: Mon Aug 24, 2009 9:34 pm |
|
|
|
Guest
|
Ben Voigt [C++ MVP] wrote:
Quote:
"Edward Diener" <eddielee_no_spam_here at (no spam) tropicsoft.com> wrote in message
news:OOsrsrNJKHA.5984 at (no spam) TK2MSFTNGP05.phx.gbl...
Ben Voigt [C++ MVP] wrote:
snip...
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 the way.
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?
I have answered this a million times but you don't want to get it. When
a company denigrates a product, how can you, or anyone else, use that
old argument that there are not enough users of that product to justify
that company spending resources on it ? It's just stupid sophistry and I
know you know that but you will insist no doubt that it must be a viable
argument for your cause. |
|
|
| Back to top |
|
|
|
| Edward Diener... |
| Posted: Mon Aug 24, 2009 9:44 pm |
|
|
|
Guest
|
Brian Muth wrote:
Quote:
"Edward Diener" <eddielee_no_spam_here at (no spam) tropicsoft.com> wrote in message
news:eHnu1d2IKHA.6068 at (no spam) TK2MSFTNGP03.phx.gbl...
Brian Muth wrote:
Nonetheless Microsoft's abysmal support for C++/CLI, along with
their almost complete refusal to fix C++/CLI bugs ...
What bugs are you referring to? I've always considered C++/CLI to be
extremely stable.
Here are bug report numbers:
101670
not found
101671
not found
101674
not found
101677
workaround provided
101678
not found
192619
not found
199186
not found
205446
not found
216882
not found
249881
not found
275035
not found
295385
not found
344776
not found
362782
not found
431084
not found
any others that I can review?
I know its real hard to go to the advanced search and put in a feedback
number, but try it nonetheless.
As far as "workaround provided" MS can provide workarounds for every bug
one has but that does not remove the simple fact that they refuse to fix
the bugs. Nobody likes to have to keep track of "workarounds" not does
anybody like to have to deal with new bugs, which others have reported
but for which a workaround is not known by the programmer. That's what
is so stupid about MS's refusal to actually fix so many bugs: they are
just wasting programmer's time. |
|
|
| Back to top |
|
|
|
| David Wilkinson... |
| Posted: Wed Aug 26, 2009 8:03 am |
|
|
|
Guest
|
Ben Voigt [C++ MVP] wrote:
Quote: 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 end.
Ben:
I absolutely agree that adding ordinary variables or methods to a class is
something I do not need or want a wizard for.
But the VC6 ClassWizard was not for that. It was for adding handlers and
control-related variables (control or value) to *MFC* classes. These things are
much more of a chore to do manually, because you have to add entries in several
places. The replacements for the VC6 ClassWizard in later VS versions are
extremely awkward to use, and often painfully slow. Not to mention being subject
to breakage by modifications to IE, as recently happened with IE8.
I think you are actually talking about Class View, which is something I have
never really used in any version of VC.
--
David Wilkinson
Visual C++ MVP |
|
|
| Back to top |
|
|
|
|
|
All times are GMT - 5 Hours
The time now is Sat Nov 28, 2009 9:06 am
|
|