First, it is legal to cast in C. §6.7.2.1/13: Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, … Read more
Yes, your program has undefined behaviour if you form such a pointer. That’s because the only way you can do so is to increment a valid pointer past the bounds of the object it points inside, and that is an undefined operation. [C++14: 5.7/5]: When an expression that has integral type is added to or … Read more
No. According to the normative wording of the standard, a definition using empty parentheses without the void keyword is not one of the forms that must be accepted, and strictly speaking the behavior of such a program is undefined. Reference: N1570 section 5.1.2.2.1. (The published 2011 ISO C standard, which is not freely available, has … Read more
Using a hyperlinked C++ grammar, the parsing of decltype(void()) is: decltype( expression ) decltype( assignment-expression ) decltype( conditional-expression ) … lots of steps involving order of operations go here … decltype( postfix-expression ) decltype( simple-type-specifier ( expression-listopt ) ) decltype( void() ) So void() is a kind of expression here, in particular a postfix-expression. Specifically, … Read more
Unfortunately, this is not easy to read. You are misreading the second case of the for statement. The first semicolon is an integral part of declaration and thus hidden to your eyes. You can easily check such syntax questions by looking into Annex A. There you have: (6.7) declaration: declaration-specifiers init-declarator-listopt ; static_assert-declaration
No, it is not. &array is of type pointer to char[SOME_SIZE] (in the first example given). This means &array + 1 points to memory immediately past the end of array. Dereferencing that (as in (*(&array+1)) gives undefined behaviour. No need to analyse further. Once there is any part of an expression that gives undefined behaviour, … Read more
Your second case is undefined behavior, you are no longer using aggregate initialization, it is still list initialization but in this case you have a user defined constructor which is being called. In order to pass the second argument to your constructor it needs to evaluate foo.i but it is not initialized yet since you … Read more
§13.3.1.7 [over.match.list]/p1: When objects of non-aggregate class type T are list-initialized (8.5.4), overload resolution selects the constructor in two phases: Initially, the candidate functions are the initializer-list constructors (8.5.4) of the class T and the argument list consists of the initializer list as a single argument. If no viable initializer-list constructor is found, overload resolution … Read more
The fact that this rule is applicable in your case is not deliberate: It’s ultimately a result of keeping the grammar simple. There is no incentive to prohibit declarations such as yours, but there are great disincentives to complicate rules, especially if those are intricate as they are. In short, if you don’t want to … Read more
The C standard says A declaration other than a static_assert declaration shall declare at least a declarator (other than the parameters of a function or the members of a structure or union), a tag, or the members of an enumeration. C++ says In a simple-declaration, the optional init-declarator-list can be omitted only when declaring a … Read more