11–20 of 30 posts
Their approach seems reasonable. If they fix this, they will break code that currently works by depending on this. They've not said that they will never fix it, just that they won't for the time being and will reconsider for a future release.
Their approach seems reasonable. If they fix this, they will break code that currently works by depending on this. They've not said that they will never fix it, just that they won't for the time being and will reconsider for a future release.
The fix could be just to issue a warning of non-compliance to C++ standards.
Earlier quoted context omitted.
Quite a valid observation from Stroustrup. But in this case the programmer has chosen to use a non-standard, vendor specific feature. So it is not clear how it applies here? (Especially given the cost of breaking existing code)
The programmer inadvertently used a vendor-specific feature. This is the key difference. Nobody writes perfect, standards-compliant code all the time, so the compiler needs to tell you when you are doing this.
Here is a much, much more serious issue. Variable length arrays of C++ types. Totally not in the C++ standard anywhere. Accepted by g++ and clang++, even if I turn on all warnings, and use '-std=c++11', which is supposed to turn off extensions. I have to add -pedantic to finally get a warning.
Now, I'm not saying they should break this code, but this is a much, much, much more serious unlabelled breakage of the standard, which is never going to get fixed, and goes back to the start of g++ and clang++.
struct X {};
int main(int argc, char** argv)
{ X a[argc]; }error: cannot call constructor ‘Thing::Thing’ directly [-fpermissive]
clang compiles the code without issuing an error.
There are real issues causing real problems which really should be fixed, very much including those related to standards compliance, but this doesn't appear to be one of them. The cure would be worse than the poison: Breaking existing codebases further, making it even harder to update legacy codebases to new toolsets, for an error made -- I'm guessing wildly here instead of verifying -- back in the VS6 era perhaps? That's a lot of code. What do we gain? We... make it slightly harder to accidentally write MSVC specific code. We already have a much, much better and more thorough tool for that: Compiling with a non MSVC compiler. I'd rather see the dev time put towards other issues.
As for not hitting C++11 standards compliance straight off the bat, they tried that for C++98 in VS6 and got burned by last minute changes. Yes, it'd be nice if they implemented everything correctly. The bug reports calling out problems with that compliance are very well and good. That said, they aren't billing themselves as feature-complete WRT C++11 yet, and I'd rather take this lackadaisical tempo than see yet another round of implementation mistakes which then need indefinite support.
Of course, this is probably colored by the fact that I don't get to use C++11 yet anyways -- out of the environments I'm currently stuck supporting, MSVC is at the bleeding edge of the curve.
Earlier quoted context omitted.
The fix could be just to issue a warning of non-compliance to C++ standards.
Except that can break compiling projects as well due to /WX (treating warnings as errors).
Having said that the issue looks fairly non-urgent and inclusion in a later release would be perfectly reasonable.
Is the implication that other teams are better with standards compliance? Here is a much, much more serious issue. Variable length arrays of C++ types. Totally not in the C++ standard anywhere. Accepted by g++ and clang++, even if I turn on all warnings, and use '-std=c++11', which is supposed to turn off extensions. I have to add -pedantic to finally get a warning. Now, I'm not saying they should break this code, bu…
(Of course, part of that is presumably that gcc's nonconformance is generally useful, as in this case...)
Is the implication that other teams are better with standards compliance? Here is a much, much more serious issue. Variable length arrays of C++ types. Totally not in the C++ standard anywhere. Accepted by g++ and clang++, even if I turn on all warnings, and use '-std=c++11', which is supposed to turn off extensions. I have to add -pedantic to finally get a warning. Now, I'm not saying they should break this code, bu…
http://isocpp.org/blog/2013/04/trip-report-iso-c-spring-2013...
That being said, you are correct that it would be good to see warnings in something other than just -pedantic for that.