Boost logo

Boost :

From: Daniel Frey (d.frey_at_[hidden])
Date: 2003-03-11 19:21:36

On Tue, 11 Mar 2003 12:22:19 +0100, Sam Partington wrote:

> As for the issue below, I also have no idea how to go about
> automatically selecting either method. Plus I think this might
> introduce complexities which make the compiler's job that much harder to
> optimise. Could well be wrong on that though.

Optimization won't bother me that much as it should all be compile-time
magic. It still has to be verified but before that, we need something
that we can verify. :)

> Essentially I think the options are to
> - document its unusual behaviour in the presence of other conversion
> operators
> - use the private operator int method.
> So if we take the plusses and minuses for each method:
> safe-bool:
> + obvious error messages (see list of error messages at end)

This is from the "convenience" section IMHO. But it's important.

> - problems with classes that provide other user-defined conversions
> operators.

A "technical" thing. The question is, what do we prefer? I personally
prefer a technical advantage as it creates safer overall code. I am used
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 project.
It compiles without a warning but calls operator int() instead of

> So it comes down to two things,
> 1) How important is it to have legible diagnostics? 2) How important is
> it to behave properly with other user-defined conversions?

The latter will probably be the result of a colleague adding operator
int() 6 month after you developed the class. What formerly worked
correctly turns into a bug silently and you will - depening on your
definition of operator int() not necessarily notice it in the beginning.
Maybe - and we all know Murphy - it provides the correct semantics in
99.9% of all cases. That's a nice bug to trace, isn't it?

But these are just my personal opinions, other opinions welcome.

> My gut feeling is that I'd rather have the safe-bool method, but I
> suspect my judgement is coloured by two things: - I never use user
> defined conversion operators - I use MSVC 6 as my main compiler, and not
> being able to do if (a && !a) would bother me.

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 explain
what exactly is ambiguous for operator&&? Does anyone know this problem
and has a work-around?

Regards, Daniel

Boost list run by bdawes at, gregod at, cpdaniel at, john at