Vladimir Prus wrote:
Peter Dimov wrote:
None (if you are sure that this is what assert does, of course - this is platform specific), except that the asserts should not fire. So spending time and effort to make something happen when the asserts fire is not productive.
I disagree. Here, two people report that they got assertion failures. Good, but we have no idea why. If there were additional diagnostic, we'd knew the exact system error which was reported.
Hm. Thorsten Froehlich reports that on Mac OS X pthread_join on a thread that has completed returns EINVAL. He is given a lecture on pthread_join. Nobody with Mac OS X access bothers to investigate, at least not visibly. Kevin Wheatley reports that the assert( res == WAIT_OBJECT_0 ) is failing for him on Windows. Printing res (WAIT_FAILED) or GetLastError() ("invalid handle" would be my bet) won't give us much information as to whether the assert is failing due to double thread::join, thread::join on a default-constructed thread, or an internal error in Boost.Threads. Your response is to add perror on Linux. :-) However I do see your point. In these situations I usually replace assert( r == 0 ); with assert( r != EINVAL ); assert( r != ESRCH ); assert( r != EDEADLK ); assert( r == 0 ); I don't claim that it's better than perror/abort when this is what assert does, print a message to stderr and call abort, but adding platform-specific error reporting sections to every assert would probably be a slippery slope.