Peter Dimov wrote:
Vladimir Prus wrote:
I interpreted Kevin's post this way -- Boost.Tread fails and does not produce any useful diagnostic.
The proper way to fix that is to make Boost.Threads not fail, right? That's what invariant/"assertion" asserts are for - to catch bugs. They aren't an error reporting mechanism.
So, what I don't know is 100% if the bug is in Boost.Threads, OS, Compiler, my application, etc, etc. What I do know is that some of my problem stems from the fact that Boost.Threads is not just a header only library, it has a library aspect to it. If everything was perfect in threads then the assertion does not help me debug my application code (assuming it is in there that the problem lies) as it discards the platforms' reasons for the error, it only states that some pre-condition assumed by the code is broken. If threads was header only then I could come up with a macro controlled mechanism for instance to enable extra output in my debugging build, this would be different to the Debug and Release build, but wouldn't require any tinkering with anything other than the files in question. For this particular application I'd like 3 states: release - no asserts, no debugging code, no nothing. debug - asserts, no debugging code. debugging - asserts, extra debugging code (Some people like to leave assertions enabled in release code, some don't) currently the built libraries only cover the first 2 cases. Getting consensus on how to deal with this in general is probably not straight forward, but maybe threads being what they are (hard to program, easy to get wrong, not always repeatable) threads could have a special case need. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |