3 ms·
After reading http://blogs.msdn.com/b/vcblog/archive/2015/09/25/rejuvenating-the-microsoft-c-c-compiler.aspx http://blogs.msdn.com/b/vcblog/archive/2015/09/25/r
by mappu 11y ago
After reading http://blogs.msdn.com/b/vcblog/archive/2015/09/25/rejuvenating-the-microsoft-c-c-compiler.aspx http://blogs.msdn.com/b/vcblog/archive/2015/09/25/rejuvenati... i'm not really surprised about these kind of issues. It's impressive that VC2013 was as compliant as it was, when all template parsing was based on string interpolation instead of an AST (and simultaneously distressing that a billion-dollar company would release such a product so recently).
Is the submitted article talking about VC2015? Although i suppose they will need to keep supporting the older toolchains.
- stinos 11y agoIs the submitted article talking about VC2015? It's a pitty it is not stated which version - maybe it means 'all versions' - nor possible fixes a user can use. E.g. for the 'Binding Rvalues to Lvalue References' case: using /W4 flag will yield a C4239 warning, turning on 'Treat warnings as error' will prevent using the code all together. For things like the '__VA_ARGS__ chaos' and 'Elimiated Types' on the other hand there is no fix (that I know of), but I'd argue such constructs do not have a place in modern C++ (or maybe even any C++ for that matter) anyway and they should be avoided by the users and as such should never turn into problems.
- asveikau 11y ago> For things like the '__VA_ARGS__ chaos' and 'Elimiated Types' on the other hand there is no fix (that I know of), but I'd argue such constructs do not have a place in modern C++ (or maybe even any C++ for that matter) anyway and they should be avoided by the users and as such should never turn into problems. The point is that massively popular libraries (Windows SDK, boost) depend on or work around the broken behavior. This attempt to ignore the problem by calling it insufficiently modern is impractical for folks who need to care in the real world.