The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

Billy Donahue (4) [Avatar] Offline
#1
Hi Anthony,

On pg31 (35 of the PDF), Listing 2.8, there's a

std::mem_fn(&std::thread::join)

Which assumes a particular overload set for std::thread::join. This is a guarantee the standard doesn't give us, but it will probably work mostly for now or something. Maybe this could be restated to avoid the member function assumption on a std:: library class.
anthony.williams (216) [Avatar] Offline
#2
Thanks for pointing this out
georger.araujo (6) [Avatar] Offline
#3
Billy Donahue wrote:Hi Anthony,

On pg31 (35 of the PDF), Listing 2.8, there's a

std::mem_fn(&std::thread::join)

Which assumes a particular overload set for std::thread::join. This is a guarantee the standard doesn't give us, but it will probably work mostly for now or something. Maybe this could be restated to avoid the member function assumption on a std:: library class.

That statement is also present in Listings 2.9, 8.2, and 8.3.

I didn't quite understand what was the issue until I stumbled upon this.

I suppose the following code would be preferable?
for (auto& t : threads)
{
    t.join();
}