Dear all, This year, MSVC conformed to the C++ Standard support, up to C++17 <https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/>, or link: https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/ I noticed a useful and meaningful feature support of C++17, which MinGW does not have yet: Refining expression evaluation order. Search for it on that page, you will see the proposal paper: P0145R3 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r3.pdf>, or link: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r3.pdf A simple example would be the *expression evaluation order of the simple assignment operator*: #include <map>int main() { std::map<int, int> m; m[0] = m.size(); // #1 } What should the map object m look like after evaluation of the statement marked #1? {{0, 0}} or {{0, 1}}? It was unspecified until C++17. The C++17 standard <http://eel.is/c++draft/expr.ass#1.sentence-5> says {{0, 0}}, because the right operand of the assignment operator is sequenced before the left operand, together with any side effect, which means the side effect of std::map::operator[], i.e. insertion, should happen after m.size() evaluates to 0. However, the latest MinGW (version info and more convincing test in P.S.) gives {{0, 1}}, even when compiling with "-std=c++17". Similarly, the new C++17 standard requires the following expressions to be evaluated in the order a, then b, then c, then d: 1. a.b (useful for chaining function calls) 2. a->b 3. a->*b 4. a(b1, b2, b3) 5. b @= a 6. a[b] 7. a << b 8. a >> b *I was trying to create a ticket for this at https://sourceforge.net/p/mingw/bugs/ <https://sourceforge.net/p/mingw/bugs/>* *but it requires admins' authorization:* [image: image.png] *Could anyone create the ticket / authorize me to do so? My account is https://sourceforge.net/u/jasonlijt/profile <https://sourceforge.net/u/jasonlijt/profile>* *Many thanks,* *Jason Li* P.S. The *self-contained test* which does not depend on STL: #include <iostream>int *getPtr(int& x) { std::cout << "getPtr(" << x << ")\n"; // Artificial side effect return &x; }int main() { int zero = 0, one = 1; *getPtr(zero) = *getPtr(one); } // Similar tests can be done with other operators using this technique Expected stdout: getPtr(1) getPtr(0) MinGW (with -std=c++17) stdout: getPtr(0) getPtr(1) Version info: Operating system: Windows 10 Pro 1803, 17134.407 gcc version 6.3.0 (MinGW.org GCC-6.3.0-1) GNU ld (GNU Binutils) 2.28 MinGW Version (found in mingw/include/_mingw.h): #define __MINGW32_VERSION 5000002L #define __MINGW32_MAJOR_VERSION 5 #define __MINGW32_MINOR_VERSION 0 #define __MINGW32_PATCHLEVEL 2 Build environment: MINGW64_NT-10.0 Jason 2.9.0(0.318/5/3) 2017-10-05 15:05 x86_64 Msys Minimal Self-Contained Test Case: see above P.S. and email Documentation or References (all retrieved on 11/19/2018): [1] Visual C++ Team Blog - Announcing: MSVC Conforms to the C++ Standard. Retrieved from: https://blogs.msdn.microsoft.com/vcblog/2018/05/07/announcing-msvc-conforms-to-the-c-standard/ [2] Refining Expression Evaluation Order for Idiomatic C++. Retrieved from: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r3.pdf [3] Assignment and compound assignment operators. Retrieved from http://eel.is/c++draft/expr.ass#1.sentence-5 [4] Rules 14-21 of https://en.cppreference.com/w/cpp/language/eval_order -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.osdn.me/mailman/archives/mingw-users/attachments/20181119/fdc751ed/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 26872 bytes Desc: not available URL: <https://lists.osdn.me/mailman/archives/mingw-users/attachments/20181119/fdc751ed/attachment-0001.png>
Fork