Re: [boost] Boost.Threads draft library submission

From: Jesse Jones (jesjones_at_[hidden])
Date: 2001-03-15 08:10:52

>Thu, Mar 15, 2001 at 02:38:51AM -0800, Jesse Jones ­Š¤‰Œ:
>> >> 2) CloseHandle can also fail, but you don't want to throw from a dtor so 
>an
>> >> assert might be good.
>> >
>> >Is there any difference? Throwing from destructor has at worst case the same
>> >effect as failed assertion; but assert usually disappears from release 
>> >builds,
>> >and throw's not.
>> 
>> Throwing from a dtor is liable to terminate your app.
>
>Only when you are unwinding stack already - otherwise it just non-desirable
>but generally safe.

Sure, but you don't know if the stack is being unwound unless you use uncaught_exception() and that's not supported by many compilers and IIRC has some sort of subtle problem.

>> Asserting will let you know something is wrong and let the app continue.
>
>Are you talking about some custom "assert"? The standard one terminates the
>application when it's condition check failed.

I guess I am. I hardly ever use the C assert. :-)

>> >> 6) It's better to provide an operator const void*() method instead of
>> >> operator bool(). (Unlike bool the const void* one won't implicitly convert
>> >> to umpteen different types).
>> >
>> >For the same reason I'm against implicit conversions when there is no real
>> >need for them; why not to provide just member function?
>> 
>> Many people like writing stuff like "if (p)". And the const void* conversion 
>operator is surprisingly safe.
>
>Well, may be; but if several typings make source more clear, I would 
>prefer to
>type them. It's matter of taste.

I used to think the same way, but I think the majority of C/C++ programmers would prefer to use "if (p)".

>> >Assert is primarilly debug tool, and library cannot depend from mode it is
>> >compiled - debug mode or release mode. It is what std::logic_error (as base
>> >class) is for.
>> 
>> That's one opinion. Another is that there are two more or less distinct 
>classes of errors: system errors like out of memory or writing to a locked 
>file and programmer errors like indexing past the end of an array. 
>Exceptions work well for system errors, but they're often overkill for 
>programmer errors. I *really* don't want every pre/post condition 
>violation and sanity check to throw an exception for every app I write. 
>
>So you prefer to just crash all the app?

These are *programmer errors*. Therefore the vast majority can be found and expunged during QA. This is fundamentally different than a system error which cannot be removed barring extreme measures like refusing to dynamicly allocate memory.

>It is not an _app_ what is written here - it is library. My opinion is that:
>even if library user (programmer) violates contract calling library 
>functions,
>the library absolutely must not to lay the application down. It is just what
>exceptions are for.

I think exceptions are more expensive than you realize. For example, I just disassembled a simple function in release with CodeWarrior 6. It comes out to 44 bytes. If I add a line that reads "if (!block) throw std::logic_error("bad param");" it balloons to 192 bytes (not counting the extra space needed for the string literal). If I add a second line that reads "if (block) throw std::logic_error("bad param2");" it grows to 308 bytes. This is not a pretty picture, especially if you use asserts heavily as I do.

Now you may be willing to pay the price of extra bloat and compromised optimizations in return for catching the few programmer errors that slip out into the field, but most people will not. Of course this is something on which reasonable people will differ so there ought to be a way for clients to affect it, but in the meantime I think boost should use assert where appropiate (and other parts of boost do).

  -- Jesse