Domagoj Saric wrote:
"Scott McMurray" <me22.ca+boost@gmail.com> wrote in message news:fa28b9251003011306k77a61047l4e0236ebbd6d8dc3@mail.gmail.com...
Is there a reason it can't just always look at operator!?
I've been using a macro like this, since I don't need the workarounds:
#define OPERATOR_SAFE_BOOL(for_type) \ typedef bool (for_type::*unspecified_bool_type)() const; \ operator unspecified_bool_type() const { \ return !*this ? 0 : &for_type::operator!; \ }
This forces classes to have operator! and it still suffers from efficiency issues outlined in the first post...
I don't think the requirement for operator! is so bad (should certainly satisfy the majority of use cases, right?), and perhaps efficiency can be addressed by defining the "unspecified_bool_type" conversion in debug builds and a straight bool conversion in release builds for "problem" compilers...? Or perhaps some other preprocessor macro can direct whether to go with the type-safe version (default) or the efficient version (which may in fact be the same for some compilers)...? - Jeff