Remix.run Logo
moralestapia 7 months ago

No, if you have temporal safety issues you didn't understand RAII. That is pretty much the whole point of RAII.

AnimalMuppet 7 months ago | parent [-]

If you want anyone to believe you, you're going to have to give more than just a blank assertion. Can you give at least a sketch of your reason for your claim?

moralestapia 7 months ago | parent [-]

Reasoning is, if your objects outlive the scope of your class, then they most likely belong to a class that's higher in the hierarchy (they already do, de facto).

SoothingSorbet 7 months ago | parent [-]

Please explain how you would solve the iterator invalidation problem using only C++ and RAII. Thanks.

moralestapia 7 months ago | parent [-]

This small thread is about temporal safety so you're out of luck.

genrilz 7 months ago | parent [-]

One, iterator invalidation can be a temporal safety problem. Specifically, if you have an iterator into a vector and you insert into the same vector, the vector might reallocate, resulting in the iterator pointing into invalid memory.

Two, consider the unique_ptr example then. Perhaps a library takes a reference to the contents of the unique_ptr to do some calculation. (by passing the reference into a function) Later, someone comes along and sticks a call to std::async inside the calculation function for better latency. Depending on the launch policy, this will result in a use after free either if the future is first used after the unique_ptr is dead, or if the thread the future is running on does not run until after the unique_ptr is dead.

EDIT: Originally I was just thinking of the person who inserted the std::async as being an idiot, but consider that the function might have been templated, with the implicit assumption that you would pass by value.