   smart pointers and undefined behavior
  Hello,I have this codebar->var = func();bar is a smart pointer and func() changes what bar points to. On all platforms we've previously used this code the bar-> is evaluated after func() is called which gives us the expected results.Now, on our latest platform and compiler bar-> is evaluated first and then func is called and it trashes on all our data.Two questions:1) Is this undefined behavior and if it is can you explain why? 2) How do most systems with smart pointers get around this, if it is undefined? Thank you,-= Dave   
  The order of evaluation of the two subexpressions "bar->var" and "func()" is implementation defined as there is no sequence point in the entire expression.I've personally never seen an expression with the kind of side effects you're describing and so have never needed to "get around it".   ;  Why is it a problem that func() is executed before or after bar-> is executed? Does func() depend on 'bar'? And why? I don't think func() should depend on 'bar' at all (neither do you pass 'bar' to func(), maybe you should to resolve this).Also, i = i + 5; also works because first the right-hand side of the equation is evaluated, then put to the left side. I cannot confirm this, but I suspect the standards would define the right hand side to be executed first.   ;Quote:Original post by David NeubeltHello,I have this codebar->var = func();bar is a smart pointer and func() changes what bar points to. On all platforms we've previously used this code the bar-> is evaluated after func() is called which gives us the expected results.Now, on our latest platform and compiler bar-> is evaluated first and then func is called and it trashes on all our data.Two questions:1) Is this undefined behavior and if it is can you explain why? There is no sequence point there except at the start of that expression and the end. That is the order of evaluation of the terms within that expression is implementation defined. so bar->var (which invokes operator->()) and func() can be evaluated in any order. Writing code that depends on a specific order is, quite frankly IDIOTIC. Fire the moron who wrote that code.Quote:2) How do most systems with smart pointers get around this, if it is undefined?Most systems don't depend on one thing being evaluated before the other within an expression.Based on what you described above, "func()" appears to change "bar", and you expect that to happen before "bar->var" is evaluated. That's imbecilic. Try separating out the code that modifies bar from that which assigns to var.   ;Quote:Original post by David Neubeltbar is a smart pointerWhich smart pointer?Quote:Fire the moron who wrote that code.I've learned to never make statements like this. They tend to backfire since "the moron" is quite frequently involved in the conversation. I also ended up firing myself quite often, but then the work needed to be done, so being cornered and out of options I had no choice but to rehire myself at higher hourly rate...   ;Quote:Original post by AntheusQuote:Original post by David Neubeltbar is a smart pointerWhich smart pointer?Quote:Fire the moron who wrote that code.I've learned to never make statements like this. They tend to backfire since "the moron" is quite frequently involved in the conversation. I also ended up firing myself quite often, but then the work needed to be done, so being cornered and out of options I had no choice but to rehire myself at higher hourly rate...I really hope you're not writing code where you're assigning to a member variable of an object referenced through a smart pointer whose value is modified by a function whose return value you are assigning to the previously mentioned member variable after said function modifies the smart pointer that you're referencing said member variable through.   ;  If you have these side-effects, then you gotta put those sequence points in there yourself.TypeOfBarVar result = func();bar->var = result;But the point of other is, having such side-effects is an accident waiting to happen.   ;Quote:Original post by WashuI really hope you're not writing code where you're assigning to a member variable of an object referenced through a smart pointer whose value is modified by a function whose return value you are assigning to the previously mentioned member variable after said function modifies the smart pointer that you're referencing said member variable through.I hope not.Until now I never even considered what would happen here:struct Foo {  void mutate() { x = // something }  X & get() { return x; }private:  X x;};foo.get() = something_that_changes_foo();This starts looking might similar to i++ problem.Still, anything similar to above requires globals, which renders all arguments invalid. Them there being evil and such.IMHO, free functions at minimum:void func(smart_ptr & x);