Rumors of reduced support for C++ /CLI

[Ben Voigt [C++ MVP]]

There are plenty of bugs in the compiler causing it to fail with

See my list in this thread and I am sure there are plenty more also.

For MS the bug never meets the "triage requirements" to fix it. Of course
that terminology is just invented MS speak for "we don't feel like fixing
the bug" and nothing more.

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.

 

[Edward Diener]

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.

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.

 

[Brian Muth]

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?

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

 

[Ben Voigt [C++ MVP]]

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.

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.

 

[Ben Voigt [C++ MVP]]

not found

Don't know why Edward didn't provide useful links, but they should look like
this (change the last six digits). Connect's search can't match issue
numbers, apparently.

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=101670

not found

any others that I can review?

I looked at about half of them. There were a couple of genuine bugs, and a
bunch of not understanding that C++ template code needs to be put into
header files, not exported from DLL's. For example, Edward claimed that it
wasn't possible to make a reusable function to convert between
System::String and std::string, but clearly the marshal_as class provided in
VS2008 does so.

The other thing I noticed was a pattern of insulting the developers. No
wonder the real bugs didn't get any response. You catch more flies with
honey....

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

And I for one am glad that Microsoft didn't "embrace and extend" C++ even
more than they have. Sure, C# got anonymous functions first, but I'm really
glad that Visual C++ is going to have them using the standard syntax instead
of coming up with something new for VS2005 that would have conflicted with
C++0x.

A bunch of other stuff like expression trees and LINQ, C++ had first in the
form of template libraries (there are some really good ones out there).
C++0x is going to make such libraries even more powerful (can anyone say
"XAML support via user-defined string literals"?).
http://www.research.att.com/~bs/C++0xFAQ.html#UD-literals

 

[Brian Muth]

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

 

[Edward Diener]

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.

 

[Edward Diener]

Don't know why Edward didn't provide useful links, but they should look
like this (change the last six digits). Connect's search can't match
issue numbers, apparently.

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=101670



I looked at about half of them. There were a couple of genuine bugs,

They were all genuine bugs. Because MS decides not to fix them, or
considers some idiotic and onerous workaround sufficient, does not make
them any less genuine.

and a bunch of not understanding that C++ template code needs to be put
into header files, not exported from DLL's.

Dream on ! You are so full of it.

For example, Edward claimed
that it wasn't possible to make a reusable function to convert between
System::String and std::string, but clearly the marshal_as class
provided in VS2008 does so.

I reported it for VS2005 when the marshal_as class did not exist. Also
my example showed I was correct at that time.

The other thing I noticed was a pattern of insulting the developers. No
wonder the real bugs didn't get any response. You catch more flies with
honey....

I never insulted anyone. I told them the truth. Too bad more people do
not do that. I don't have to lie to MS in order to please them.

And I for one am glad that Microsoft didn't "embrace and extend" C++
even more than they have. Sure, C# got anonymous functions first, but
I'm really glad that Visual C++ is going to have them using the standard
syntax instead of coming up with something new for VS2005 that would
have conflicted with C++0x.

C++/CLI is Microsoft's own language. Like C# they can change it at will.
Arguments to the contrary are just excuses. Sure they would like to
maintain compatibility with C++ on the purely C++ native parts of
C++/CLI, but they have already made enough changes to support .Net that
adding some more to support .Net technologies is not going to upset any
C++ programmer. After all they have continued to change C# with each no
release, and no C# programmer is scurring away in disgust.

Herb Sutter did a great job with C++/CLI but MS refused to follow up and
make it a first class .Net language.

A bunch of other stuff like expression trees and LINQ, C++ had first in
the form of template libraries (there are some really good ones out
there).

Good ! Then there is even less reason for MS not supporting C++/CLI as
it should have. You have justified my arguments even though you supposed
you were just being clever arguing against me.

C++0x is going to make such libraries even more powerful (can
anyone say "XAML support via user-defined string literals"?).
http://www.research.att.com/~bs/C++0xFAQ.html#UD-literals

One doesn't need C++Ox to do XAML visually. This is just a red herring.

 

[Ben Voigt [C++ MVP]]

They were all genuine bugs. Because MS decides not to fix them, or
considers some idiotic and onerous workaround sufficient, does not make
them any less genuine.


Dream on ! You are so full of it.

There is only one mechanism for binary template reuse in C++ -- "export".
And there's exactly one compiler that supports it, and that one isn't Visual
C++. Everyone else distributes reusable template code as header files.

I reported it for VS2005 when the marshal_as class did not exist. Also my
example showed I was correct at that time.

Sorry, nothing in the compiler changed to make marshal_as work. It just
wasn't bundled in VS2005, but you could download it from the marshal_as.net
(or whatever the website for it was) and use it just fine.

I never insulted anyone. I told them the truth. Too bad more people do not
do that. I don't have to lie to MS in order to please them.

You didn't go out of your way to make sure it wouldn't be perceived as
insulting either.

I value the bare truth. Many people do not. Lack of tact tends to make
people uncooperative.

C++/CLI is Microsoft's own language. Like C# they can change it at will.
Arguments to the contrary are just excuses. Sure they would like to
maintain compatibility with C++ on the purely C++ native parts of C++/CLI,
but they have already made enough changes to support .Net that adding some
more to support .Net technologies is not going to upset any C++
programmer. After all they have continued to change C# with each no
release, and no C# programmer is scurring away in disgust.

But C++/CLI allows mixing native and managed code -- the same syntax has to
be supported in both.

Herb Sutter did a great job with C++/CLI but MS refused to follow up and
make it a first class .Net language.

It doesn't seem to be the language you're complaining about though. Just
the tools.

Good ! Then there is even less reason for MS not supporting C++/CLI as it
should have. You have justified my arguments even though you supposed you
were just being clever arguing against me.

I'm saying that much of what people perceive as not being supported in
C++/CLI actually is, by virtue of the very flexible language design. Now it
does require some follow through to write the libraries, but not compiler
changes. Which means that anybody can add those features, not just
Microsoft.

One doesn't need C++Ox to do XAML visually. This is just a red herring.

Microsoft makes visual XAML design tools available. I thought you were
complaining about the lack of integration with C++ at the source code level.
That's what C++0x user-defined string literals.