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:
--
templateclass T, class B = ::boost::detail::empty_base struct
other_bool_testable : B
{
public:
operator bool() const { return !!static_castconst T(*this); }
private:
typedef signed char private_number_type;
operator private_number_type() const;
};
#if defined(USE_OTHER_BOOL_TESTABLE)
class A : public other_bool_testableA
#else
class A : public bool_testableA
#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_testableclass A,class
boost::detail::empty_base'
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_testableA,boost::detail::empty_base::operator bool() const
test.cpp:9:
other_bool_testableA,boost::detail::empty_base::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_testableA,boost::detail::empty_base::operator bool() const
test.cpp:9:
other_bool_testableA,boost::detail::empty_base::operator signed char()
const
test.cpp:9: `other_bool_testableA,boost::detail::empty_base::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: 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=delr=ie=UTF-8frame=rightth=d0969f0fa2460dd4seekm=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 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
[boost] Re: possible addition to operators library
On Fri, 07 Mar 2003 19:42:44 +0100, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: At 11:08 AM 3/7/2003, David Abrahams wrote: Sam Partington [EMAIL PROTECTED] writes: Hi all, Hate to sound pushy, but I've no answer on this, were the patches ok? Would you like me to repost them? Or should I just drop it? The code looks OK, but the submission won't be complete without patches for the docs and tests. The submission was three files, including patches for docs and tests. The only one I could find was a single patch. Can someone point to the message in the archive please? http://www.mail-archive.com/boost%40lists.boost.org/msg05908.html 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. 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. Regards, Daniel ___ 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
[boost] Re: possible addition to operators library
On Fri, 07 Mar 2003 11:46:24 +0100, Sam Partington wrote:
Hate to sound pushy, but I've no answer on this, were the patches ok?
Daniel Frey wrote:
No problem. IIRC it was Peter Dimov who came up with the safe-bool
idiom first. At least I saw it first from him. Another way which
works but results in worse error messages is this:
template class T, class B = ::boost::detail::empty_base struct
bool_testable : B
{
private:
operator int() const;
public:
operator bool() const
{
return !!static_cast T ( *this );
}
};
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
may sound weird, an example hopefully clears things up:
#include iostream
using namespace std;
#include boost/operators.hpp
struct A : boost::bool_testable A
{
bool operator!() const { cout operator! endl; return false; }
operator int() const { cout operator int() endl; return 42; }
};
int main()
{
A a;
if( a )
cout Hello, world! endl;
// int i = a;
// long l = a;
}
The code above happily compiles without warnings but it calls operator
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=delr=ie=UTF-8frame=rightth=d0969f0fa2460dd4seekm=3A2D10EE.35544D0A%40aixigo.de#link1
Thoughts?
Regards, Daniel
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: possible addition to operators library
On Tue, 25 Feb 2003 21:14:14 +0100, David Abrahams wrote: Daniel Frey [EMAIL PROTECTED] writes: David Abrahams wrote: Daniel Frey [EMAIL PROTECTED] writes: That won't work as you made it a nested struct so it is still different for all instantiations. I think Dave meant to go for this one: Yup, that's what I meant. BTW, so this safe_bool thing can get further re-used it might make sense to make a special friend class which just has access to the type... or at that point, just make the type publicly accessible. Can you elaborate a bit? I imagine that although the technical implementation might be identical, the sematics of the names could be a problem. Can you elaborate a bit? How could the semantics be a problem? As Doug already showed it's a problem when you use the same safe_bool for all your classes as a replacement for operator bool. I though that you have some other uses in mind that are more than just a replacement for operator bool. If so, I wondered what this could be and if the name would then be a problem. If it's just meant to replace operator bool, the names are perfect - although the problem Doug mentioned remains. Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
