Poor (and nearly-incorrect) example for rule F.27 (shared_ptr) about cppcoreguidelines HOT 4 CLOSED

Editors call: Thanks! We agree this would be clearer with a destruction of im.

from cppcoreguidelines.

@hsutter :

We agree this would be clearer with a destruction of im.

Something like this perhaps?

{
  std::shared_ptr<const Image> im { read_image(somewhere) };

  std::thread t0 {shade, args0, top_left, image};
  std::thread t1 {shade, args1, top_right, image};
  std::thread t2 {shade, args2, bottom_left, image};
  std::thread t3 {shade, args3, bottom_right, image};

  // detach threads
}
// main thread no longer shares ownership
// last thread among t0-t3 to finish deletes the image

or maybe even

{
  std::shared_ptr<const Image> image { read_image(somewhere) };

  std::thread{shade, args0, top_left, image}.detach();
  std::thread{shade, args1, top_right, image}.detach();
  std::thread{shade, args2, bottom_left, image}.detach();
  std::thread{shade, args3, bottom_right, image}.detach();
}
// main thread no longer shares ownership
// last thread among the four shader threads to finish deletes the image

?

from cppcoreguidelines.

Yes, that's pretty much the direction we had in mind 👍

from cppcoreguidelines.

@hsutter : So, this bug is not actually resolved. After the new commit, the code as written results in std::terminate being called - as there is now not even a placeholder for the threads getting detached. You're saying that "detaching thread requires care etc." - but the detaching is not said to occur.

This will confuse users (and doubly so if they mistakenly imagine that the destruction involves joining - which they might believe happens; under that mis-perception, the use-case would actually be better served by a plain scoped Image rather than the shared_ptr. It's better to be extra clear in distinguishing the intended use case from the very-typical false use case for smart pointers.

Bottom line: Please either actually detach (which isn't hard after all), or say the threads get detached, explicitly.

from cppcoreguidelines.