6 ms·

C++ compiler accepts explicit constructor call

24 points by 430gj9j 13y ago

Piskvorrr 13y ago
In a changing world, you can depend on Microsoft: "Where you want to go today? Meh, as if we care; we have already decided on that."
430gj9j 13y ago
And also here: http://connect.microsoft.com/VisualStudio/feedback/details/779916/decltype-and-declval-dont-work-as-expected http://connect.microsoft.com/VisualStudio/feedback/details/7... And again: http://connect.microsoft.com/VisualStudio/feedback/details/778613/c-compiler-template-type-deduction-with-function-and-overloaded-operators http://connect.microsoft.com/VisualStudio/feedback/details/7...
- Jare 13y ago
  See http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2274165-speed-up-work-on-vc- http://visualstudio.uservoice.com/forums/121579-visual-studi... as well
ambrop7 13y ago
Unless this breaks valid C++ code, I don't see how they need care too much about fixing it, especially since that would break existing code.
- 430gj9j 13y ago
  A quote from Stroustrup: "Use of a supplier's language extensions and non-standard-conforming features limits the portability of your code and can prevent you from choosing a new implementation supplier." http://www.stroustrup.com/compilers.html http://www.stroustrup.com/compilers.html
  - shadowfox 13y ago
    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)
    - 430gj9j 13y ago
      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.
      - ambrop7 13y ago
        Right, but it's a trivial fix, in this case at least. I'm happy as long as standard code works in their compiler. Considering how much trouble MS are having with getting their compiler standard-conformant, I'd rather they work on the more important features.
  - lmm 13y ago
    A sibling thread claims the same syntax is supported by clang, and allowed by gcc using -fpermissive, so it seems like that's not a practical concern in this instance.
hyperbling 13y ago
seems standard. visual studio releases are years behind each other so they're not going to fix anything that's not critical.
jfoster 13y ago
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.
- LanceH 13y ago
  The fix could be just to issue a warning of non-compliance to C++ standards.
  - BudVVeezer 13y ago
    Except that can break compiling projects as well due to /WX (treating warnings as errors).
    - josephlord 13y ago
      Those projects want to be warned of non-compliant code and they have chosen to have their build break on questionable constructs. I think that this is a weak argument for not issuing a warning. Having said that the issue looks fairly non-urgent and inclusion in a later release would be perfectly reasonable.
CJefferson 13y ago
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, 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]; }
- BudVVeezer 13y ago
  Dynamic arrays will be in C++14. http://isocpp.org/blog/2013/04/trip-report-iso-c-spring-2013-meeting 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.
- to3m 13y ago
  Standards nonconformance has always been less of a problem when gcc does it. (Of course, part of that is presumably that gcc's nonconformance is generally useful, as in this case...)
  - pjmlp 13y ago
    FOSS developers like to forget that GCC is also full of language extensions and nonconformance issues. This is pretty standard type of issues for any ANSI/ISO language regardless of the vendor. Oh boy the joys of doing C and C++ development across multiple OS in the late 90's with commercial compilers.
    - snogglethorpe 13y ago
      Gcc was pretty wild-n-wooly back in the '90s, and seemed to add language extensions left and right, but that attitude changed quite a while ago, and it's very good about standards conformance these days (part of the reason for this, of course is it's no longer so necessary: many of these extensions have picked up by the standard in one form or another). In my experience, gcc is also significantly better with standards conformance than VC++, either with default settings or with strict warning/conformance options turned on. [I was on a team doing shared g++/vc++ develeopment, and it fell to me to fix all the code checked in by devs using non-standard VC++ extensions... way, way, way too much time... >< ]
monk_the_dog 13y ago
Just for fun, I checked that code with gcc 4.6 and clang 3.2. gcc gives the error: error: cannot call constructor ‘Thing::Thing’ directly [-fpermissive] clang compiles the code without issuing an error.
MaulingMonkey 13y ago
While I'm all for improved adherence to standards, the original linked bug report seems like a terrible case to pick a bone about attitudes towards standards compliance with. 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.
pjmlp 13y ago
How is this different from any other commercial vendor?
cheez 13y ago
In the scope of compliance issues, that is not a huge issue because no C++ developer would write that code.
andyjohnson0 13y ago
Please don't editorialise submission titles. Titling a submission "Visual C++ team's attitude to standards compliance" and pointing it at a bug report for some minor non-conforming behaviour tells us nothing useful about the msvc teams attitude to standards. Neither does the brief response from the team on that page. All it says is that there is an issue that they're not going to fix at the moment. Microsoft have a lot of customers, and those customers have a lot of code that they don't want to suddenly break without a good reason. Do some work. Find or write a useful article investigating the c++ teams attitude to standards compliance and post a link to that. If it compared msvc to other compilers then I'd read it.
frou_dh 13y ago
When I last worked with Windows and would end up on that Microsoft Connect site fairly regularly by Googling, I don't think I ever saw a response that would be satisfactory to the reporter. "Thank for for holding; your call is important to us" or "No", possibly rephrased a few times, was about your lot.
fabriceleal 13y ago
C++ noob here. This reminded me of "Obscure C++ Features" [1] (discussion [2]) - the 'Placement new' feature. Basically, we can allocate memory using malloc and then call the constructor on the allocated memory: // Must allocate our own memory Test *ptr = (Test *)malloc(sizeof(Test)); // Use placement new new (ptr) Test; // Must call the destructor ourselves ptr->~Test(); // Must release the memory ourselves free(ptr); My point is: is possible that the explicit constructor call feature is intended to be used in this use case? [1]: http://madebyevan.com/obscure-cpp-features/ http://madebyevan.com/obscure-cpp-features/ [2]: https://news.ycombinator.com/item?id=5577631 https://news.ycombinator.com/item?id=5577631

24 points by 430gj9j 13y ago

In a changing world, you can depend on Microsoft: "Where you want to go today? Meh, as if we care; we have already decided on that."

430gj9j 13y ago

And also here: http://connect.microsoft.com/VisualStudio/feedback/details/779916/decltype-and-declval-dont-work-as-expected http://connect.microsoft.com/VisualStudio/feedback/details/7... And again: http://connect.microsoft.com/VisualStudio/feedback/details/778613/c-compiler-template-type-deduction-with-function-and-overloaded-operators http://connect.microsoft.com/VisualStudio/feedback/details/7...

Jare 13y ago
See http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2274165-speed-up-work-on-vc- http://visualstudio.uservoice.com/forums/121579-visual-studi... as well

ambrop7 13y ago

Unless this breaks valid C++ code, I don't see how they need care too much about fixing it, especially since that would break existing code.

430gj9j 13y ago
A quote from Stroustrup: "Use of a supplier's language extensions and non-standard-conforming features limits the portability of your code and can prevent you from choosing a new implementation supplier." http://www.stroustrup.com/compilers.html http://www.stroustrup.com/compilers.html
- shadowfox 13y ago
  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)
  - 430gj9j 13y ago
    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.
    - ambrop7 13y ago
      Right, but it's a trivial fix, in this case at least. I'm happy as long as standard code works in their compiler. Considering how much trouble MS are having with getting their compiler standard-conformant, I'd rather they work on the more important features.
- lmm 13y ago
  A sibling thread claims the same syntax is supported by clang, and allowed by gcc using -fpermissive, so it seems like that's not a practical concern in this instance.

hyperbling 13y ago

seems standard. visual studio releases are years behind each other so they're not going to fix anything that's not critical.

jfoster 13y ago

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.

LanceH 13y ago
The fix could be just to issue a warning of non-compliance to C++ standards.
- BudVVeezer 13y ago
  Except that can break compiling projects as well due to /WX (treating warnings as errors).
  - josephlord 13y ago
    Those projects want to be warned of non-compliant code and they have chosen to have their build break on questionable constructs. I think that this is a weak argument for not issuing a warning. Having said that the issue looks fairly non-urgent and inclusion in a later release would be perfectly reasonable.

CJefferson 13y ago

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, 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]; }

BudVVeezer 13y ago
Dynamic arrays will be in C++14. http://isocpp.org/blog/2013/04/trip-report-iso-c-spring-2013-meeting 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.
to3m 13y ago
Standards nonconformance has always been less of a problem when gcc does it. (Of course, part of that is presumably that gcc's nonconformance is generally useful, as in this case...)
- pjmlp 13y ago
  FOSS developers like to forget that GCC is also full of language extensions and nonconformance issues. This is pretty standard type of issues for any ANSI/ISO language regardless of the vendor. Oh boy the joys of doing C and C++ development across multiple OS in the late 90's with commercial compilers.
  - snogglethorpe 13y ago
    Gcc was pretty wild-n-wooly back in the '90s, and seemed to add language extensions left and right, but that attitude changed quite a while ago, and it's very good about standards conformance these days (part of the reason for this, of course is it's no longer so necessary: many of these extensions have picked up by the standard in one form or another). In my experience, gcc is also significantly better with standards conformance than VC++, either with default settings or with strict warning/conformance options turned on. [I was on a team doing shared g++/vc++ develeopment, and it fell to me to fix all the code checked in by devs using non-standard VC++ extensions... way, way, way too much time... >< ]

monk_the_dog 13y ago

Just for fun, I checked that code with gcc 4.6 and clang 3.2. gcc gives the error: error: cannot call constructor ‘Thing::Thing’ directly [-fpermissive] clang compiles the code without issuing an error.

MaulingMonkey 13y ago

While I'm all for improved adherence to standards, the original linked bug report seems like a terrible case to pick a bone about attitudes towards standards compliance with. 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.

pjmlp 13y ago

How is this different from any other commercial vendor?

cheez 13y ago

In the scope of compliance issues, that is not a huge issue because no C++ developer would write that code.

andyjohnson0 13y ago

Please don't editorialise submission titles. Titling a submission "Visual C++ team's attitude to standards compliance" and pointing it at a bug report for some minor non-conforming behaviour tells us nothing useful about the msvc teams attitude to standards. Neither does the brief response from the team on that page. All it says is that there is an issue that they're not going to fix at the moment. Microsoft have a lot of customers, and those customers have a lot of code that they don't want to suddenly break without a good reason. Do some work. Find or write a useful article investigating the c++ teams attitude to standards compliance and post a link to that. If it compared msvc to other compilers then I'd read it.

frou_dh 13y ago

When I last worked with Windows and would end up on that Microsoft Connect site fairly regularly by Googling, I don't think I ever saw a response that would be satisfactory to the reporter. "Thank for for holding; your call is important to us" or "No", possibly rephrased a few times, was about your lot.

fabriceleal 13y ago

C++ noob here. This reminded me of "Obscure C++ Features" [1] (discussion [2]) - the 'Placement new' feature. Basically, we can allocate memory using malloc and then call the constructor on the allocated memory: // Must allocate our own memory Test *ptr = (Test *)malloc(sizeof(Test)); // Use placement new new (ptr) Test; // Must call the destructor ourselves ptr->~Test(); // Must release the memory ourselves free(ptr); My point is: is possible that the explicit constructor call feature is intended to be used in this use case? [1]: http://madebyevan.com/obscure-cpp-features/ http://madebyevan.com/obscure-cpp-features/ [2]: https://news.ycombinator.com/item?id=5577631 https://news.ycombinator.com/item?id=5577631