mardi 29 décembre 2015

Is this resource leak provided by possible evaluation order or Scott Meyers is wrong?

I am reading about std::shared_ptr in the Effective Modern C++14 book by Scott Meyers. Here is a code in which the author says a potentital resource leak can be:

int computePriority(); // this function always throw an exception
// ...
processWidget(std::shared_ptr<Widget>(new Widget), // (S.M): potentital
              computePriority());                  // resource
                                                   // leak

Scott Meyers says that computePriority() function may be called between new Widget and std::shared_ptr<Widget>(expr) expressions are evaluated what will lead to a memory leak caused by new. Should not be there a one sequence point that can guarantee if the new Widget expression is evaluated then std::shared_ptr<Widget>(expr) will be evaluated next? I think about this because It would be correct in my opinion: sequence point is in std::shared_ptr<Widget>(expr) will evaluate all of it's arguments(sub expressions) without sequencing and will make shared pointer be ready, then do something else (evalute other arguments without sequencing). Just if this is untrue and Scott Meyers is right (I still believe him, obviously) , would not be this behavior incorrect?

Is there a rule that explains why is this possible? I am not good at sequence points, but people who told me about them says this should be valid.

Aucun commentaire:

Enregistrer un commentaire