language-lawyer

问题 According to [basic.lookup.unqual]/8 from N4140 the following snippet should compile. But it doesn't in clang, gcc and vs2013. struct C { void f(I) {} using I = int; }; [basic.lookup.unqual]/8 (emphases are mine): For the members of a class X , a name used in a member function body, in a default argument, in an exception-specification , in the brace-or-equal-initializer of a non-static data member (9.2), or in the definition of a class member outside of the definition of X , following the

问题 At least by the C11 standard and from what I've read. The only place where return type is not allowed to be an array type is in the section of function definitions (at $6.9.1.3): The return type of a function shall be void or a complete object type other than array type. At function calls ($6.5.2.2.1) it states this: The expression that denotes the called function shall have type pointer to function returning void or returning a complete object type other than an array type . Which means that

问题 Accessing objects via reinterpret_cast ed pointers and related UB has been extensively discussed here. After reading questions and answers, I'm still not sure about proper using uninitialized memory with POD types. Suppose I want to "emulate" struct { double d; int i; }; by manually allocating memory for data members and suppose (for simplicity) that no padding is needed before i . Now, I do this: // (V1) auto buff = reinterpret_cast<char*>(std::malloc(sizeof(double) + sizeof(int))); auto d

问题 i was fooling around with the following code and got different results using my visual studio 2017 application and two different online compilers. in release mode visual studio does elide the copy/move in both cases, while the two online compilers just do it in case of the unparenthesized return statement. my question is: who is right and more importantly what are the underlaying rules. (i know you can use the parentheses in conjunction with the decltype(auto) syntax. but this is not the

问题 This is a spinoff from invoking the copy constructor within the constructor. I believe that an object is fully formed and can be expected to behave as such by the end of the initialiser list (edit: I was wrong about this though!). Specifically, member functions and accessing local state from within the constructor itself will behave exactly as they would from any other member function. This seems to be a slightly contentious point of view though, the alternative is that only once the

问题 Base on the C++ standard. The trivial copyable class are define as following: According to 9/5, A trivially copyable class is a class that: - has no non-trivial copy constructors (12.8), - has no non-trivial move constructors (12.8), - has no non-trivial copy assignment operators (13.5.3, 12.8), - has no non-trivial move assignment operators (13.5.3, 12.8), and - has a trivial destructor (12.4). By my understanding, the trivially copyable class is which can be copied by bitwise copied. So

问题 3.4.1 1 implementation-defined behavior unspecified behavior where each implementation documents how the choice is made Can an implementation specify that, implementation-defined behavior is undefined behavior in cases where undefined behavior is a possible outcome? For example: 6.3.1.3 Signed and unsigned integers 3 Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised. So as long

问题 Consider the following code snippet: class A { int b[A::a]; //1, error void foo(){ int b = A::a; } //2, ok static const int a = 5; } Clause 3.4.3.1/1 (Qualified name lookup, class members) said: If the nested-name-specifier of a qualified-id nominates a class, the name specified after the nested-name-specifier is looked up in the scope of the class (10.2) This implies that the name a after the nested-name-specifier both in //1 and in //2 will be looked up in the class scope. Clause 10.2

问题 In C, an array normally isn't allowed to have size 0 (unless I use the one or other compiler-side extension). OTOH, there are VLAs whose length might turn out to be 0. Are they allowed? I am talking about the following code: void send_stuff() { char data[4 * !!flag1 + 2 * !!flag2]; uint8_t cursor = 0; if (flag1) { // fill 4 bytes of data into &data[cursor] cursor += 4; } if (flag2) { // fill 2 bytes of data into &data[cursor] cursor += 2; } } The result is a data array with a length of 0, 2,

问题 Simple code to use either unique_ptr or shared_ptr as a scope guard. All information about what to clear is captured in the deleter , so I though it is safe to use nullptr for constructor. Apparently, with Visual C++ 2017 (14.1), it is not working as expected for unique_ptr , but works for shared_ptr . Is it a Microsoft quirk, or does the standard prevent calling the deleter of a unique_ptr when holding nullptr ? In the code below, I'm forced to construct a unique_ptr with (void*)1 . If I