Re: [boost] Re: possible addition to operators library
Thanks for your comments Daniel, I will update the docs with a better
rationale and post the patch soon.
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.
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)
- problems with classes that provide other user-defined conversions
operators.
- requires declaration of operator! by user, which is a bit backward.
private operator int :
+ user provides operator bool, and our helper protects it from misuse, and
provides operator!
+ no clashes with other user-defined converion operators
- fails to work with if(a && func()) on MSVC 6 at least - 'operator && is
ambiguous'
- less helpful diagnostic messages.
The if (a && something) is quite a serious defect, but it compiles fine on
gcc 2.95.3.
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?
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.
San
Diagonostic samples:
--
template struct
other_bool_testable : B
{
public:
operator bool() const { return !!static_cast(*this); }
private:
typedef signed char private_number_type;
operator private_number_type() const;
};
#if defined(USE_OTHER_BOOL_TESTABLE)
class A : public other_bool_testable
#else
class A : public bool_testable
#endif
{
public:
bool operator!() const { return false; }
};
void f(int);
void g(signed char);
void test(const A& a)
{
if (a && !a)
{
f(a);
g(a);
}
}
MSVC 6
***
safe-bool:
test.cpp(321) : error C2664: 'f' : cannot convert parameter 1 from 'const
class A' to 'int'
No user-defined-conversion operator available that can perform this
conversion, or the operator cannot be called
private operator :
test.cpp(319) : error C2593: 'operator &&' is ambiguous
// when the conversion is not an exact match to the private operator i.e.
int to signed char
test.cpp(347) : error C2664: 'f' : cannot convert parameter 1 from 'const
class A' to 'int'
Ambiguous user-defined-conversion
//when it is an exact match
test.cpp(322) : error C2248: 'operator`signed char'' : cannot access private
member declared in class 'other_bool_testable'
C:\Work\SS\debugger\CodeScape\CBuilder.cpp(323) : see declaration of
'operator`signed char''
gcc 2.95.3 :
*
safe-bool:
test.cpp: In function `void test(const A &)':
test.cpp:32: `const class A' used where a `int' was expected
with the private operator some_number() :
// if the private operator is not an exact match (e.g signed char to an int)
test.cpp:32: conversion from `const A' to `int' is ambiguous
test.cpp:6: candidates are:
other_bool_testable::operator bool() const
test.cpp:9:
other_bool_testable::operator signed char()
const
// if the private operator is an exact match you get
test.cpp:32: conversion from `const A' to `signed char' is ambiguous
test.cpp:6: candidates are:
other_bool_testable::operator bool() const
test.cpp:9:
other_bool_testable::operator signed char()
const
test.cpp:9: `other_bool_testable::operator
signed char() const' is private
test.cpp:35: within this context
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: possible addition to operators library
Daniel Frey wrote: > > BTW: I wonder if gmane eats messages. I cannot find some messages we > exchanged when I was still in the company earlier this day. I will keep an > eye on it in case the problem remains. False alarm, gmane.org works perfectly well. I just had to fix my mail-filters :) Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: possible addition to operators library
Daniel Frey wrote: > > One problem I just found with your implementation (and thus with Peter's > idiom in general) is, that is doesn't provide an operator bool(). This This sounds too hard. Of course it's not a problem where Peter used it as there obviously is no other operator int() or something. The problem only occurs when you try to create a generic component that should work with all classes. > [...] > int(). Several options come to mind: > > - Document it that the class T of bool_testable< T > shall not have any > other operators that might conflict. > - Use the above alternative implementation I showed. It is not as nice as > yours/Peter's wrt error-messages, but it works as expected. > - Convince the standard committee that "explicit operator bool" is needed > :) See: > http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&frame=right&th=d0969f0fa2460dd4&seekm=3A2D10EE.35544D0A%40aixigo.de#link1 Another alternative would be to create a selector which switches from the safe-bool-idiom to a real operator bool when appropriate. This would involve type-traits I guess and as a start we could try to detect convertability to bool of the class T. But this is IMHO not sufficient, as T might have operator int() and operator long(), so the detection will fail (ambiguous). Although this alternative would lead to the best result, I don't have a clever idea how to achieve that... Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: possible addition to operators library
Daniel Frey <[EMAIL PROTECTED]> writes: > Sam: I looked at the patches, especially the doc. I think you should write > some more, as you were influenced from your knowledge. I suggest you begin > with mentioning operator bool() and what's wrong with it before presenting > the solution. Think of new users that potentially don't even know that > there is a problem with operator bool(). Also, if you like, you can write > a brief note about why the "classic" solution I showed (using a private > operator int() in parallel to operator bool()) is not a good solution and > how yours/Peter's is better. All this can/should happen in the note you > added. The note itself should be added to the index at the top and you > might want to add yourself to the contributors' list at the end. Very nice remarks, Daniel. I have full confidence in you as the new maintainer of the operators library. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
