language-lawyer

问题 Is type punning arrays of the same type but with a different size still a violation of strict aliasing? int arr[4]; int(&ref)[2] = reinterpret_cast<int(&)[2]>(arr); arr[0] = 0; //write to original ref[0]; //read from pun 回答1: We can argue as follows; [expr.reinterpret.cast]/11: A glvalue expression of type T1 can be cast to the type “reference to T2 ” if an expression of type “pointer to T1 ” can be explicitly converted to the type “pointer to T2 ” using a reinterpret_cast . The result refers

问题 Consider this union: union A{ int a; struct{ int b; } c; }; c and a are not layout-compatibles types so it is not possible to read the value of b through a : A x; x.c.b=10; x.a+x.a; //undefined behaviour (UB) Trial 1 For the case below I think that since C++17, I also get an undefined behavior: A x; x.a=10; auto p = &x.a; //(1) x.c.b=12; //(2) *p+*p; //(3) UB Let's consider [basic.type]/3: Every value of pointer type is one of the following: a pointer to an object or function (the pointer is

问题 Consider: struct empty {}; struct child : empty { empty a[sizeof(int) / sizeof(empty)]; int b; }; // Assume sizeof(int) >= sizeof(empty) Does the standard mandate that sizeof(child) is more than 2 * sizeof(int) ? The way I see it, nothing prohibits the baseclass-subobject from sharing its address with member b . If not, are there any common ABIs exploiting that at all? 回答1: Let us first check the rule that allows empty base class optimization to acquaint ourselves with the terminology: N4659

问题 (I am studying for the Java Associate Exam OCJP 7) A question asked to select examples of illegal initializations. One of the answers was:- int [] k= new int[2]{5,10}; The explanation said that when creating an anonymous array it was illegal to specify the size of the array. From what I know this is NOT an anonymous array as it is named "k". Calling a method such as :- operateOnArray(new int[]{5,10}); Would have been an example of an anonymous array since it is not declared. I can see that

问题 This question is inspired by answers to this question. Following code has potential for undefined behaviour: uint64_t arr[1]; // Uninitialized if(arr[0] == 0) { C standard specifies that uninitialized variable with automatic storage duration has indeterminate value , which is either unspecified or trap representation . It also specifies that uintN_t types have no padding bits, and size and range of values are well defined; so trap representation for uint64_t is not possible. So I conclude

问题 While thinking how CRTP can be improved in C++11 , I ended with the following code: template <typename Derived, typename Delayer> struct derived_value_type { typedef typename Derived::value_type type; }; template <typename Derived> struct base { template <typename Delayer = void> typename derived_value_type<Derived, Delayer>::type foo(){ return {}; } }; struct derived : base<derived> { typedef int value_type; }; #include <iostream> #include <typeinfo> int main() { derived d; auto bar = d.foo(

问题 Per this presentation, if either the copy constructor or copy assignment operator is "user declared", then no implicit move operations will be generated. Does delete ing the copy constructor or copy assignment operator count as "user declared"? struct NoCopy { NoCopy(NoCopy&) = delete; NoCopy& operator=(const NoCopy&) = delete; }; Will implicit move operations be generated for the NoCopy class? Or does deleting the relevant copy operations count as "user declared" and thus inhibit implicit

问题 Consider the following code: int i = 1; char c[sizeof (i)]; memcpy(c, &i, sizeof (i)); cout << static_cast<int>(c[0]); Please ignore whether this is good code. I know the output depends on the endianness of the system. This is only an academic question. Is this code: Undefined behaviour Implementation-defined behaviour Well-defined behaviour Something else 回答1: The rule you are looking for is 3.9p4: The object representation of an object of type T is the sequence of N unsigned char objects

问题 Question: If pointers comparing equals are their integer-converted values also equal? For example: void *ptr1 = //... void *ptr2 = //... printf("%d", ptr1 == ptr2); //prints 1 Does it mean that (intptr_t) ptr1 == (intptr_t) ptr2 is also 1 ? From pragmatic point of view that should be right. But considering what the Standard specifies at 7.20.1.4(p1) : The following type designates a signed integer type with the property that any valid pointer to void can be converted to this type, then

问题 I received an issue on GitHub about my ES2015 module import/export validating plugin for ESLint not recognizing the default export in the following syntax: export { foo as default, bar } where my plugin will lint the following (equivalent?) syntax no problem: export default foo; export const bar = ..; Both Babel and Esprima parse similar syntax without errors, and this works for code using Babel on both ends (import and export). However, I'm not convinced the spec allows the former export { x