I think you’re right, it’s not possible to implement memmove efficiently in standard C. The only truly portable way to test whether the regions overlap, I think, is something like this: for (size_t l = 0; l < len; ++l) { if (src + l == dst) || (src + l == dst + len … Read more
Both are correct. Implementation defined behavior is a particular type of unspecified behavior. Citing section 3.4.1 of the C standard which defines “implementation-defined behavior”: 1 implementation-defined behavior unspecified behavior where each implementation documents how the choice is made 2 EXAMPLE An example of implementation-defined behavior is the propagation of the high-order bit when a signed … Read more
Short answer No. Explanation [namespace.std] says: Let F denote a standard library function ([global.functions]), a standard library static member function, or an instantiation of a standard library function template. Unless F is designated an addressable function, the behavior of a C++ program is unspecified (possibly ill-formed) if it explicitly or implicitly attempts to form a … Read more
Use list initialization to construct B. The elements are then guaranteed to be evaluated from left to right. C(std::unique_ptr<A> a) : B{a->x, std::move(a)} {} // ^ ^ – braces From §8.5.4/4 [dcl.init.list] Within the initializer-list of a braced-init-list, the initializer-clauses, including any that result from pack expansions (14.5.3), are evaluated in the order in which … Read more
The expression f() + g() contains a minimum of 4 sequence points; one before the call to f() (after all zero of its arguments are evaluated); one before the call to g() (after all zero of its arguments are evaluated); one as the call to f() returns; and one as the call to g() returns. … Read more
A language lawyer question. Hmkay. My personal top3: violating the strict aliasing rule violating the strict aliasing rule violating the strict aliasing rule 🙂 Edit Here is a little example that does it wrong twice: (assume 32 bit ints and little endian) float funky_float_abs (float a) { unsigned int temp = *(unsigned int *)&a; temp … Read more
The code exhibits unspecified behavior due to unspecified order of evaluation of sub-expressions although it does not invoke undefined behavior since all side effects are done within functions which introduces a sequencing relationship between the side effects in this case. This example is mentioned in the proposal N4228: Refining Expression Evaluation Order for Idiomatic C++ … Read more
Undefined behavior is one of those aspects of the C and C++ language that can be surprising to programmers coming from other languages (other languages try to hide it better). Basically, it is possible to write C++ programs that do not behave in a predictable way, even though many C++ compilers will not report any … Read more