Darren Cook wrote:
It's certainly not to be done without understanding the ramifications. ...
But the same user will be equally unprepared to unspecified evaluation order in
A = get(), get(), get();
and in
A.assign_list(get())(get())(get()) ;
There's nothing specific about operator,();
Wouldn't A << get() << get() << get() ;
always work the way the user expects,
I think user will still expect specific evaluation order above. And from standard point of view, it does not have more sequence points than either of the other versions. Finally, this still looks like formatted insertion to me.
even when they switch all optimizations on?
It's almost impossible (IMO) for compiler to get the unexpected evaluation order in either case. For agruments of one function call, compiler will likely to evaluate arguments either staring from the first one, or from the last one, depending on the calling conversion. But for: operator()(get()).operator()(get()).operator()(get()) (or for comma), it's very unlikely that compiler will start by evaluating all 'get()' calls and then proceed by calling operator(). It's a strange logic to implement, and would require you too keep all results from 'get()' somewhere, increasing register pressure. So maybe, it's mostly theoretic issue. - Volodya