gcc8

C++17 filesystem using nuwen MinGW on Windows 10

萝らか妹 提交于 2020-06-12 02:52:53
问题 I wanted to try out the new filesystem library in C++17, so tried copying the std::filesystem::current_path example from cppreference.com and compiling it using the latest version (16.0) of the MinGW distribution from nuwen.net on my Windows 10 x64 machine. This includes gcc v8.1 which should support the filesystem library according to cppreference.com compiler support page. Here is the code that I am trying to compile: #include <iostream> #include <filesystem> namespace fs = std::filesystem;

C++17 filesystem using nuwen MinGW on Windows 10

为君一笑 提交于 2020-06-12 02:49:27
问题 I wanted to try out the new filesystem library in C++17, so tried copying the std::filesystem::current_path example from cppreference.com and compiling it using the latest version (16.0) of the MinGW distribution from nuwen.net on my Windows 10 x64 machine. This includes gcc v8.1 which should support the filesystem library according to cppreference.com compiler support page. Here is the code that I am trying to compile: #include <iostream> #include <filesystem> namespace fs = std::filesystem;

gcc-8 -Wstringop-truncation what is the good practice?

烂漫一生 提交于 2020-01-03 08:49:33
问题 GCC 8 added a -Wstringop-truncation warning. From https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82944 : The -Wstringop-truncation warning added in GCC 8.0 via r254630 for bug 81117 is specifically intended to highlight likely unintended uses of the strncpy function that truncate the terminating NUL charcter from the source string. An example of such a misuse given in the request is the following: char buf[2]; void test (const char* str) { strncpy (buf, str, strlen (str)); } I get the same

Does the behavior of guaranteed copy elision depend on existence of user-defined copy constructor?

半世苍凉 提交于 2019-12-03 08:54:04
问题 The following code behaves differently with or without user-defined copy constructor under GCC 8.0.1: #include <cassert> struct S { int i; int *p; S() : i(0), p(&i) {} // S(const S &s) : i(s.i), p(&i) {} // #1 // S(const S &s) : i(s.i), p(s.p) {} // #2 // S(const S &s) = delete; // #3 }; S make_S() {return S{};} int main() { S s = make_S(); assert(s.p == &s.i); } With either of the commented user-defined copy constructors (even with #2, the one performing a simple shallow copy), the assertion

Does the behavior of guaranteed copy elision depend on existence of user-defined copy constructor?

醉酒当歌 提交于 2019-12-02 22:52:13
The following code behaves differently with or without user-defined copy constructor under GCC 8.0.1 : #include <cassert> struct S { int i; int *p; S() : i(0), p(&i) {} // S(const S &s) : i(s.i), p(&i) {} // #1 // S(const S &s) : i(s.i), p(s.p) {} // #2 // S(const S &s) = delete; // #3 }; S make_S() {return S{};} int main() { S s = make_S(); assert(s.p == &s.i); } With either of the commented user-defined copy constructors (even with #2, the one performing a simple shallow copy), the assertion will not fail, which means guaranteed copy elision works as expected. However, without any user