On Sat, 25 Jan 2003 19:17:35 -0500, David Abrahams <[EMAIL PROTECTED]> wrote:
>It's hard for me to justify any other interpretations under a strict >reading of the standard. Yes. >I am tempted to open a DR about this, but >I'm not sure exactly how much we should ask for. Shooting for the >moon, we could ask that an expression can only invoke undefined >behavior if it is "potentially evaluated", c.f. 3.2/2 That solves the problem when you wrap the function call in a sizeof; but leaves undefined behavior for Peter's example, where the call is never performed. I would say that one should allow undefined behavior only if the call is actually executed (I should rather say: when the call-expression is actually evaluated, to take into account inlining. But I'm trying to use a simpler language). Basically I find that the standard is all but crystal clear when it comes to the difference between a function-call expression (banally: a sequence of "signs" written in the program text) and a function call in its run-time meaning. Take for instance the beginning of 5.2.2/4: "When a function is called, each parameter (8.3.5) shall be initialized (8.5, 12.8, 12.1) with its corresponding argument. When a function is called, the parameters that have object type shall have completely-defined object type." It uses the phrase "When a function is called" two times: in the second case it clearly refers to the function call expression, not to the actual call of the function; so the "when" is to be interpreted as "at the point of". In the first case I tend to think instead that it refers to the run-time call, because initialization of function parameters (as I intend it) is a run-time operation. Note in fact that, immediately after, the standard says: " **During** the initialization of a parameter" IMHO trying to think initialization as a purely formal (and thus compile-time) operation is a little problematic. Coming back to the main point, I think that if the standard was more clear in the distinction between a call and a call-expression we wouldn't have any chance to ask ourselves whether f( non_pod ); is undefined or not: either the standard would say that writing the function-call expression is undefined (thus even if it is in a sizeof), or that actually calling the function is undefined. Personally, I think it should be the second one and that Peter's example should have a well-defined behavior. Genny. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
