Re: [boost] possible addition to operators library
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? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
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. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
"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. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
Sam Partington wrote: > > 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? No, please don't drop it. I think it's a good idea, but I haven't found the time to look at your patches closely. I will try to do so but I can't promise any shedule. Besides: I remember that the first message about the NRVO-implementation I wrote was about June 2002 and it took several months to get it accepted. Just be patient and keep reminding the group (and the maintainers of operators.hpp) from time to time :) 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] possible addition to operators library
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?
Cheers
Sam
- Original Message -
From: "Sam Partington" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Thursday, February 27, 2003 10:55 AM
Subject: Re: [boost] possible addition to operators library
> Daniel Frey wrote:
> >>
> >> 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
> > struct bool_testable : B
> > {
> > private:
> > operator int() const;
> >
> > public:
> > operator bool() const
> > {
> > return !!static_cast< T& >( *this );
> > }
> > };
> >
> > It should be a more efficient implementation for most of the points
> > Dave mentioned and it should also work in all cases (allowing the use
> > as a bool, int is private, thus not accessible and other conversions,
> > e.g. to 'long' are ambiguous. The drawback is, that the error
> > messages are not as clear and obvious as for Peter's idiom.
>
> Well we'll stick with Peter's model then. I had figured it was Peter,
> someone let me know if it wasn't.
>
> Sam Partington (me!) wrote:
> > Is there another alternative to this? How about this:
> >
> > typedef void (bool_testable::*unspecified_bool_type)() const;
> > operator unspecified_bool_type() const
> > {
> >return !static_cast(*this) ? 0 :
> > reinterpret_cast(&bool_testable::operator
> > unspecified_bool_type);
> > }
> >
> >
> > Does this have any issues that I can't see? Ideally we could avoid
> > the reinterpret_cast, but how do you express the type of a
> > user-defined conversion operator for the type you're trying to
> > express? Beats me!
>
> I was hoping for a response to this, but I know we're all busy, so I'll
take
> the silence to mean that noone has any serious objections. I know lots of
> you will see the reinterpret_cast and start shouting "non-portable" but in
> this case all its doing is casting the return type of the function
pointer.
> Also we're not going to use the pointer other than a compare to zero, so
> providing there are no compilers that would reinterpret_cast to a zero, I
> don't see a problem.
>
> This is my preferred solution for now, as it avoids a lot of the overhead
> problems that have worried some of you.
>
> I've attached the patches, including docs and test.
>
> Sam
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
Daniel Frey wrote:
>>
>> 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
> struct bool_testable : B
> {
> private:
> operator int() const;
>
> public:
> operator bool() const
> {
> return !!static_cast< T& >( *this );
> }
> };
>
> It should be a more efficient implementation for most of the points
> Dave mentioned and it should also work in all cases (allowing the use
> as a bool, int is private, thus not accessible and other conversions,
> e.g. to 'long' are ambiguous. The drawback is, that the error
> messages are not as clear and obvious as for Peter's idiom.
Well we'll stick with Peter's model then. I had figured it was Peter,
someone let me know if it wasn't.
Sam Partington (me!) wrote:
> Is there another alternative to this? How about this:
>
> typedef void (bool_testable::*unspecified_bool_type)() const;
> operator unspecified_bool_type() const
> {
>return !static_cast(*this) ? 0 :
> reinterpret_cast(&bool_testable::operator
> unspecified_bool_type);
> }
>
>
> Does this have any issues that I can't see? Ideally we could avoid
> the reinterpret_cast, but how do you express the type of a
> user-defined conversion operator for the type you're trying to
> express? Beats me!
I was hoping for a response to this, but I know we're all busy, so I'll take
the silence to mean that noone has any serious objections. I know lots of
you will see the reinterpret_cast and start shouting "non-portable" but in
this case all its doing is casting the return type of the function pointer.
Also we're not going to use the pointer other than a compare to zero, so
providing there are no compilers that would reinterpret_cast to a zero, I
don't see a problem.
This is my preferred solution for now, as it avoids a lot of the overhead
problems that have worried some of you.
I've attached the patches, including docs and test.
Sam
operators_test.cpp.patch
Description: Binary data
operators.htm.patch
Description: Binary data
operators.hpp.patch
Description: Binary data
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
Sam Partington wrote:
>
> Daniel Frey wrote:
> > I also think it would be fair to mention Dave as a contributor, too,
> > as he provided the way to reduce the overhead.
>
> Of course, that bit was still there from the first time through, also
> whoever came up with the original "unspecified-bool-type" idiom needs
> acknowledged as well. No offence intended, merely laziness. Sorry.
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
struct bool_testable : B
{
private:
operator int() const;
public:
operator bool() const
{
return !!static_cast< T& >( *this );
}
};
It should be a more efficient implementation for most of the points Dave
mentioned and it should also work in all cases (allowing the use as a
bool, int is private, thus not accessible and other conversions, e.g. to
'long' are ambiguous. The drawback is, that the error messages are not
as clear and obvious as for Peter's idiom.
> David Abrahams wrote:
> > It's very nice, but you left out the most-important parts: patches
> > for the docs and testsuite.
:))
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] possible addition to operators library
Hi all,
Sorry I've been off air for a bit. I'll try to answer as much as I can in
this email.
Daniel Frey wrote:
> I also think it would be fair to mention Dave as a contributor, too,
> as he provided the way to reduce the overhead.
Of course, that bit was still there from the first time through, also
whoever came up with the original "unspecified-bool-type" idiom needs
acknowledged as well. No offence intended, merely laziness. Sorry.
David Abrahams wrote:
> "Sam Partington" <[EMAIL PROTECTED]> writes:
>> Also seems to me that anyone who declares a global template operator!
>> deserves some problems!
> I don't know why you think so.
Well, I don't mean that they deserve to be stoned to death or anything! But
they are going to be seeing some strange things anyway. I don't think us
providing with them another operator is going to cause them any more issues.
>> So, now with David's suggestion, I've attached what I propose.
>>
>> I've tested to a small extent on MSVC6 and gcc 2.95, which are all
>> the compilers I have access to now.
>>
>> (First time I've used a patch file so apologies if I've messed it up)
>
> It's very nice, but you left out the most-important parts: patches
> for the docs and testsuite.
How did I know someone would pull me up on that :-) I'm working on them, I
just need to get a handle on the test suite first. I was fairly sure that
the code patch was going to be enough to get us discussing for now.
Douglas Paul Gregor wrote:
> myclass m;
> yourclass y;
>
> if (m == y) {
> // what's this mean?
> }
>
> This is the reason boost::function has poisoned operator== and
> operator!=.
Doesn't this require two user defined conversions, which stops this from
being possible? However I agree we should avoid possible problems like
this. The idea behind "unspecified-bool-type" is to return an obscure type
that can't be accidentally used where not expected - so I would say make it
as obscure as possible. To me this means a private nested struct. Which
I'll come to in a minute.
Daniel Frey wrote:
> 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:
This was intentional for the reason I've just stated above. I don't see
this as any efficiency problem, as certainly on the two compilers I've tried
there was no instantiation of safe_bool at all, without optimisations. With
optimisations on all of the code inlined into the ideal x != 0. Ok on
_some_ compilers this may be an issue, but that goes for just about all
things in boost.
As for making safe_bool reusable, I can only see one possible reason. Where
someone would want to make if (x) a valid construct but not if (!p). Is
this enough reason to allow it? If so then it does not really belong in
boost/operators.hpp, more likely boost/utitlity.hpp.
Is there another alternative to this? How about this:
typedef void (bool_testable::*unspecified_bool_type)() const;
operator unspecified_bool_type() const
{
return !static_cast(*this) ? 0 :
reinterpret_cast(&bool_testable::operator
unspecified_bool_type);
}
Does this have any issues that I can't see? Ideally we could avoid the
reinterpret_cast, but how do you express the type of a user-defined
conversion operator for the type you're trying to express? Beats me!
Sam
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
On Tue, 25 Feb 2003, David Abrahams wrote:
> namespace boost
> {
>struct safe_bool
>{
>int value;
>typedef int safe_bool::*type;
>};
> }
>
> struct myclass
> {
>operator boost::safe_bool::type() const
>{
> return expression ? &boost::safe_bool::value : 0;
>}
> };
You don't want to do that. Add:
struct yourclass
{
operator boost::safe_bool::type() const
{
return expression? &boost::safe_bool::value : 0;
}
};
myclass m;
yourclass y;
if (m == y) {
// what's this mean?
}
This is the reason boost::function has poisoned operator== and operator!=.
Doug
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
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?
> Helping the compiler to remove unneeded instantiations is a
> good thing, but it shouldn't affect readability, so I'd like to see some
> more concrete uses and whether we can use safe_bool (or any other name)
> that matches all these "typical" uses.
namespace boost
{
struct safe_bool
{
int value;
typedef int safe_bool::*type;
};
}
struct myclass
{
operator boost::safe_bool::type() const
{
return expression ? &boost::safe_bool::value : 0;
}
};
HTH,
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
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. Helping the compiler to remove unneeded instantiations is a good thing, but it shouldn't affect readability, so I'd like to see some more concrete uses and whether we can use safe_bool (or any other name) that matches all these "typical" uses. 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] possible addition to operators library
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. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
"Sam Partington" <[EMAIL PROTECTED]> writes: > I think I agree, we want to provide as little restrictions as possible. > > Also seems to me that anyone who declares a global template operator! > deserves some problems! I don't know why you think so. > So, now with David's suggestion, I've attached what I propose. > > I've tested to a small extent on MSVC6 and gcc 2.95, which are all the > compilers I have access to now. > > (First time I've used a patch file so apologies if I've messed it up) It's very nice, but you left out the most-important parts: patches for the docs and testsuite. > Sam > > PS Did anyone who uses OE-Quote notice what a mess it made of the wrapping, > interpreting > B>:: as three seperate reply inserts? and so miss out the B, and substitute >> > >. ;-) Great program 99% of the time though. Yep. I went back to emacs, though. It's still better overall for my needs. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
Sam Partington wrote:
>
> I think I agree, we want to provide as little restrictions as possible.
Dave's argument is a good one. I agree, too.
> So, now with David's suggestion, I've attached what I propose.
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:
// bool_testable contributed by Sam Partington
-//
template
struct bool_testable;
struct safe_bool
{
#ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS
private:
template friend class bool_testable;
#endif
int x;
typedef int safe_bool::*type;
};
template
struct bool_testable : B
{
operator safe_bool::type() const
{
return !static_cast(*this) ? 0 : &safe_bool::x;
}
};
I also think it would be fair to mention Dave as a contributor, too, as
he provided the way to reduce the overhead.
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] possible addition to operators library
Daniel Frey <[EMAIL PROTECTED]> writes:
> Sam Partington wrote:
>>
>> I thought of this too, but this limits the user to using a member based
>> operator!. So I couldn't do this :
>>
>> class A : public boost::bool_testable
>> {
>> public:
>> int get();
>> };
>>
>> bool operator!(const A& a)
>> {
>> return a.get() == 0;
>> }
>>
>> Of course I've never actually wanted to do that, so its maybe not a problem.
>
> In fact this is what I want to prevent. Consider a global operator! with
> a template parameter:
>
> template< typename T > bool operator!( const T& t )
> {
> return t.get() == 0;
> }
I would probably never write that. This, however:
template bool operator( foobar const& );
is just fine.
> This may lead to "accidents" I tried to avoid. We now have to decide
> whether want to allow
I vote allow.
> it or to prevent it. Sadly you cannot use &T::~T
> :)
>
>> Then again, how much does the safe_bool_conversion function cost?
>
> Not much.
Depends what you're measuring. Number of template instantiations?
Compilation time? Link time? Executable image size? All of these
may be affected.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
I think I agree, we want to provide as little restrictions as possible.
Also seems to me that anyone who declares a global template operator!
deserves some problems!
So, now with David's suggestion, I've attached what I propose.
I've tested to a small extent on MSVC6 and gcc 2.95, which are all the
compilers I have access to now.
(First time I've used a patch file so apologies if I've messed it up)
Sam
PS Did anyone who uses OE-Quote notice what a mess it made of the wrapping,
interpreting
B>:: as three seperate reply inserts? and so miss out the B, and substitute
> > >. ;-) Great program 99% of the time though.
David Abrahams wrote:
> "Sam Partington" <[EMAIL PROTECTED]> writes:
>
>> I thought of this too, but this limits the user to using a member
>> based operator!. So I couldn't do this :
>>
>> class A : public boost::bool_testable
>> {
>> public:
>> int get();
>> };
>>
>> bool operator!(const A& a)
>> {
>> return a.get() == 0;
>> }
>>
>> Of course I've never actually wanted to do that, so its maybe not a
>> problem. After all the conversion operator itself has to be a
>> member, so it probably isn't much of a restriction at all.
>
> Ahem. The operators library is *all about* defining free function
> operators. I don't think you should introduce a dependence on being
> a member function.
>
>> Then again, how much does the safe_bool_conversion function cost?
>
> More than I'd like. I'd prefer to use a single data member pointer,
> since it's likely to be more efficient.
>
>struct safe_bool
>{
> #ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS
> private:
>template friend class bool_testable;
> #endif
>int x;
>typedef int safe_bool::*type;
>};
bool_testable.patch
Description: Binary data
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
Sam Partington wrote:
>
> I thought of this too, but this limits the user to using a member based
> operator!. So I couldn't do this :
>
> class A : public boost::bool_testable
> {
> public:
> int get();
> };
>
> bool operator!(const A& a)
> {
> return a.get() == 0;
> }
>
> Of course I've never actually wanted to do that, so its maybe not a problem.
In fact this is what I want to prevent. Consider a global operator! with
a template parameter:
template< typename T > bool operator!( const T& t )
{
return t.get() == 0;
}
This may lead to "accidents" I tried to avoid. We now have to decide
whether want to allow it or to prevent it. Sadly you cannot use &T::~T
:)
> Then again, how much does the safe_bool_conversion function cost?
Not much. I think we should find an agreed on goal to achive, the
implementation follows naturally. What do you (and others) think? Should
we allow or prevent non-const-member-function-operator!-implementations?
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] possible addition to operators library
"Sam Partington" <[EMAIL PROTECTED]> writes:
> I thought of this too, but this limits the user to using a member based
> operator!. So I couldn't do this :
>
> class A : public boost::bool_testable
> {
> public:
> int get();
> };
>
> bool operator!(const A& a)
> {
> return a.get() == 0;
> }
>
> Of course I've never actually wanted to do that, so its maybe not a problem.
> After all the conversion operator itself has to be a member, so it probably
> isn't much of a restriction at all.
Ahem. The operators library is *all about* defining free function
operators. I don't think you should introduce a dependence on being
a member function.
> Then again, how much does the safe_bool_conversion function cost?
More than I'd like. I'd prefer to use a single data member pointer,
since it's likely to be more efficient.
struct safe_bool
{
#ifndef BOOST_NO_MEMBER_TEMPLATE_FRIENDS
private:
template friend class bool_testable;
#endif
int x;
typedef int safe_bool::*type;
};
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
Daniel Frey wrote:
> Nice idea! I already had something similar in mind, but you managed to
> make it really generic.
Not really, all I've done is to borrow the code from shared_ptr, and to put
into a shape like one of the existing unary operator helpers in
operator.hpp. Thanks anyway though :-)
> The only problem I see is that an instance of safe_bool_conversion is
> created which is not really needed. I suggest to rely on the operator!
> provided by T:
>
> template< class T, class B = ::boost::detail::empty_base >
> struct bool_testable : B
> {
> private:
>typedef bool (T::*unspecified_bool_type)() const;
>
> public:
>operator unspecified_bool_type() const
>{
> return !static_cast< const T& >( *this ) ? 0 : &T::operator!();
>}
> };
I thought of this too, but this limits the user to using a member based
operator!. So I couldn't do this :
class A : public boost::bool_testable
{
public:
int get();
};
bool operator!(const A& a)
{
return a.get() == 0;
}
Of course I've never actually wanted to do that, so its maybe not a problem.
After all the conversion operator itself has to be a member, so it probably
isn't much of a restriction at all.
Then again, how much does the safe_bool_conversion function cost?
Sam
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
Daniel Frey wrote:
>
> The only problem I see is that an instance of safe_bool_conversion is
> created which is not really needed. I suggest to rely on the operator!
> provided by T:
>
> template< class T, class B = ::boost::detail::empty_base >
> struct bool_testable : B
> {
> private:
>typedef bool (T::*unspecified_bool_type)() const;
>
> public:
>operator unspecified_bool_type() const
>{
> return !static_cast< const T& >( *this ) ? 0 : &T::operator!();
Should be ...operator!; without the braces, sorry.
>}
> };
It has another advantage: It makes the compiler complain if the user
didn't provided an operator! with the right signature. This is - in this
case and IMHO - a good thing.
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] possible addition to operators library
> Essentially you supply a operator! and it supplies an unspecified-bool-type
> conversion operator.
Nice idea! I already had something similar in mind, but you managed to
make it really generic.
> //Key
> //T: primary operand type
> //t: values of type T
>
> // TemplateSupplied Operations Requirements
> //
> // bool_testable operator unspecified-bool-type() !t
>
> template struct
> bool_testable : B
> {
> private:
> void safe_bool_conversion() const { }
> public:
>
> typedef void (bool_testable::*unspecified_bool_type)() const;
> operator unspecified_bool_type() const
> {
>return !static_cast(*this) ? 0 : &bool_testable B>::safe_bool_conversion;
> }
The only problem I see is that an instance of safe_bool_conversion is
created which is not really needed. I suggest to rely on the operator!
provided by T:
template< class T, class B = ::boost::detail::empty_base >
struct bool_testable : B
{
private:
typedef bool (T::*unspecified_bool_type)() const;
public:
operator unspecified_bool_type() const
{
return !static_cast< const T& >( *this ) ? 0 : &T::operator!();
}
};
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] possible addition to operators library
"Sam Partington" <[EMAIL PROTECTED]> writes:
> Hi,
>
> While making myself an interim shared_resource class, I found myself reusing
> the shared_ptr safe-bool conversion, and thought that really the idiom ought
> to go into the operators library.
>
> I am unsure about the name, but for now bool_testable seems to match the
> naming style used by the rest of operators, and be reasonably clear about
> its intent. Any suggestions gratefully received
>
> Essentially you supply a operator! and it supplies an unspecified-bool-type
> conversion operator.
>
>
> //Key
> //T: primary operand type
> //t: values of type T
>
>
> // TemplateSupplied Operations Requirements
> //
> // bool_testable operator unspecified-bool-type() !t
>
> template struct
> bool_testable : B
> {
> private:
> void safe_bool_conversion() const { }
> public:
>
> typedef void (bool_testable::*unspecified_bool_type)() const;
> operator unspecified_bool_type() const
> {
>return !static_cast(*this) ? 0 : &bool_testable B>::safe_bool_conversion;
> }
> };
>
> Any problems with this?
None that I can see.
If you want to submit it, make a patch that includes changes to the
tests and the documentation, and post it here *as an attachment* so
that line-wrapping doesn't wreck it ;-)
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
