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 operator!(). > 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost