From: Sam Partington (Sam.Partington_at_[hidden])
Date: 2003-03-12 10:58:29
> A "technical" thing. The question is, what do we prefer? I personally
> prefer a technical advantage as it creates safer overall code. I am
> to work with several people in a large code-base and in my experience
> it's always a very helpful thing if the interface of your code leads
> to compile-errors when misused. Documentation will help you to reject
> the responsibility - it won't help you to get the job done. If the
> compiler rejects your code and the error message itself is anything
> but clear, you
> are at least forced to work on it. That's not nice in the moment you
> are faced with it, but in the long term it pays.
> The alternative (keep the safe-bool and document it) leads to hidden
> bugs that are IMHO hard to find. Remember that we have a very close
> view to a
> tiny code fraction. Imagine it to be the part of a 100.000 lines
> It compiles without a warning but calls operator int() instead of
No, I agree. You're right, much better to squint at error messages than to
try and diagnose unexpected behaviour. Plus the messages I compared against
were not all that bad to look at anyway, and all of them said something to
the effect of "can't convert class 'A' to 'int' or something.
> The VC issue bothers me, as I don't think I fully understand what
> exactly happens. Doesn't the compiler give any additional messages to
> what exactly is ambiguous for operator&&? Does anyone know this
> and has a work-around?
Unfortunately I don't understand this. It can go in the documentation,
with the work around to be :
if (!!a && ...)
Which, while a little annoying, is not a fatal problem. And hopefully the
number of VC6 users should drop drastically when VC7.1 comes out anyway.
Incidentally it compiles fine on Comeau.
Finally, if we choose this route, this means that we can take the approach
of providing operator! and a private operator some_number_type() while the
user provides operator bool. This is more semantically correct in my
opinion, anyone have any problems with this?
Oh, I should have patches posted very soon.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk