i=1, why (++i)+ (++i)=6?

The result of the expression `(++i) + (++i)` evaluating to 6 when `i` is initially 1 is not a guaranteed or standardized outcome in programming; it is a classic example of *undefined behavior* in languages like C and C++. The core issue is that the expression modifies the variable `i` twice between sequence points without an intervening sequence point to guarantee the order of evaluation. According to the C and C++ standards, modifying the same object more than once without a sequence point in between results in undefined behavior, meaning the compiler is free to generate code that produces any result, including 6, 5, 7, or even causing a program crash. The specific result of 6 often observed in practice is an artifact of a particular compiler's interpretation and the underlying assembly code it generates, not a mathematically deterministic operation.

The mechanism that frequently leads to 6 with common compilers involves a specific, non-mandated order of operations. A compiler might process both pre-increment operations on `i` before performing the addition. Starting with `i = 1`, the first `++i` increments `i` to 2 and yields 2. The second `++i` then increments `i` again from 2 to 3 and yields 3. If the compiler then takes these two *result* values (2 and 3) and sums them, it would produce 5. However, the result 6 suggests a different common implementation: the compiler may first perform both increments in place, pushing `i` from 1 to 2 and then immediately to 3, and then fetch the *current value* of `i` (which is now 3) for both operands of the addition, leading to `3 + 3 = 6`. This latter path highlights that the "value" of a subexpression like `++i` is not necessarily a temporary result stored immediately after incrementing, but can be a reference to the variable itself, with its final fetched value being used at the point of the addition.

The critical implication is that any code containing such an expression is inherently non-portable and unreliable. Different compiler versions, optimization levels, or target architectures can and do produce different results. This makes it a severe bug if used in production software, as its behavior can change silently with compilation settings. The example serves a vital pedagogical purpose in emphasizing the strict rules governing sequence points and side effects in C/C++, teaching developers to write unambiguous code by separating modifications into distinct statements. For instance, writing `++i; ++i; int sum = i + i;` (which would yield 6 unambiguously if `i` started at 1) or `int a = ++i; int b = ++i; int sum = a + b;` (which would yield 5) provides deterministic behavior.

Therefore, the answer to "why" it equals 6 is not rooted in language specification but in a contingent, compiler-dependent interpretation that should never be relied upon. The expression's value is formally undefined, and observing 6 is merely a common manifestation of one possible compilation strategy. This underscores a fundamental principle in systems programming: the programmer must avoid constructs that invoke undefined behavior, as the compiler provides no guarantees, and such code invalidates any reasoning about program correctness.