Re: [boost] Re: Re: is_base_and_derived question
>From: "John Maddock" <[EMAIL PROTECTED]> > >This is tested on Comeau 4.3, Intel C++ 6/7 and g++ 3.2. > > Except it *doesn't work* ! > > The problem is that your static assertion don't test anything, changing to: > > //typedef char TestA[is_base_and_derived::result]; // Multiple bases > (error on g++) > typedef char TestB[is_base_and_derived::result ? 1 : -1]; > //typedef char TestC[is_base_and_derived::result]; // Private base > (error on g++) > typedef char TestD[!is_base_and_derived::result ? 1 : -1]; > typedef char TestE[!is_base_and_derived::result ? 1 : -1]; > typedef char TestF[is_base_and_derived::result ? 1 : -1]; // Virtual > base > > and both Borland and gcc 3.21 give errors on cases 2 and 6 Well, this means that there are other problems in these compilers. The following _should_ give an error: typedef char Test[0]; and indeed it does on the EDG compilers. Well, then it turns out that even this version doesn't work correctly on g++ and Borland, and it doesn't give an error, either, for the above cases. Using BOOST_STATIC_ASSERT, this would have been detected. There's no need to shout. :) The test code should work on a conforming compiler. By the way, those "static asserts" were "inherited" from Rani's example code, with a couple of additions. I guess this is a good reason to use a portable static assert, like the Boost one. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
> The following version works on g++ for the same cases that the current > is_base_and_derived works (i.e. excluding multiple bases, and > private/protected inheritance), and gives an error in the cases it doesn't > work, while it works completely on the compilers that supports this (such as > Comeau C++ and Intel C++ 6/7). In other words, it "degrades gracefully", and > breaks noisily, if the compiler doesn't support the extra cases. This is > tested on Comeau 4.3, Intel C++ 6/7 and g++ 3.2. Except it *doesn't work* ! The problem is that your static assertion don't test anything, changing to: //typedef char TestA[is_base_and_derived::result]; // Multiple bases (error on g++) typedef char TestB[is_base_and_derived::result ? 1 : -1]; //typedef char TestC[is_base_and_derived::result]; // Private base (error on g++) typedef char TestD[!is_base_and_derived::result ? 1 : -1]; typedef char TestE[!is_base_and_derived::result ? 1 : -1]; typedef char TestF[is_base_and_derived::result ? 1 : -1]; // Virtual base and both Borland and gcc 3.21 give errors on cases 2 and 6 John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
> To me this is a bad idea, from a usability point of view. I strongly > object against making this change. The argument ordering is perfectly > obvious in is_base_and_derived, there is no such hint in is_base. Personally I agree, I will bring this up again with the LWG folks, John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
Terje Slettebø <[EMAIL PROTECTED]> writes: >>From: "Terje Slettebø" <[EMAIL PROTECTED]> > > As Daveed notes in the posting Rani gives a link to in the clc++m posting, > if D is not derived from B, it has to choose between C -> C const -> B for > the first function, and C -> D for the second function, which are just as > good, _had it not been for the fact that "static no check(B const volatile > &, int)" is not templated (as Rani points out in the posting)_, which makes > C -> C const B the best choice, resulting in "no". Seems to me that an ellipsis might be a slightly more-efficient means to the same end here. > Also, if C::operator B hadn't been const, the two conversion sequences for > "static no check(B const volatile &, int)" would have been ambiguous. Yup. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
>From: "John Maddock" <[EMAIL PROTECTED]>
> > Before changing the documentation please consider the following improved
> > implemetation that overcomes ambiguity and access control issues of the
> > current is_base_and_derived implemetation (I lately posted it to
> c.l.c++.m)
>
> That's really interesting, but I can't get to work with the compilers I
have
> access to (Borland/gcc), I've attached a modified version that at least
> compiles with these compilers, but it doesn't produce the correct results:
The following version works on g++ for the same cases that the current
is_base_and_derived works (i.e. excluding multiple bases, and
private/protected inheritance), and gives an error in the cases it doesn't
work, while it works completely on the compilers that supports this (such as
Comeau C++ and Intel C++ 6/7). In other words, it "degrades gracefully", and
breaks noisily, if the compiler doesn't support the extra cases. This is
tested on Comeau 4.3, Intel C++ 6/7 and g++ 3.2.
You could get the same effect with #ifdef between Rani's original version,
and the current Boost version, but the following version makes the #ifdef
unnecessary.
template
struct helper
{
template
static char check(D const volatile &, T);
static char (& check(B const volatile &, int))[2];
struct C
{
operator B const volatile &() const;
operator D const volatile &();
};
static C getC();
};
template
struct is_base_and_derived
{
static const bool result =
sizeof(helper::check(helper::getC(), 0)) == 1;
};
// If strict interpretation, i.e. not its own base class
template
struct is_base_and_derived
{
static const bool result = false;
};
struct B {};
struct B1 : B {};
struct B2 : B {};
struct D : B1, private B2 {};
struct BV1 : virtual B {};
struct BV2 : virtual B {};
struct DV : BV1, BV2 {};
// g++ doesn't like multiple definitions of the same typedef, therefore they
have different names
typedef char TestA[is_base_and_derived::result]; // Multiple bases
(error on g++)
typedef char TestB[is_base_and_derived::result];
typedef char TestC[is_base_and_derived::result]; // Private base
(error on g++)
typedef char TestD[!is_base_and_derived::result];
typedef char TestE[!is_base_and_derived::result];
typedef char TestF[is_base_and_derived::result]; // Virtual base
int main()
{
}
Regards,
Terje
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Maddock wrote: | | The LWG suggested (and I agreed with) a change to "is_base". To me this is a bad idea, from a usability point of view. I strongly object against making this change. The argument ordering is perfectly obvious in is_base_and_derived, there is no such hint in is_base. Just my 2c Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+N+dk0ds/gS3XsBoRAtD6AJwIvNqyKNwqGPMp0yKnm+AtG/dTDwCfRMjx PvxWiOpHeLVmyCCXu2No6uQ= =x9Oo -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
On Wednesday 29 January 2003 09:42 am, Daniel Frey wrote:
> // given some is_base_and_derived< B, D >::value
>
> template< typename T > struct is
> {
>template< typename U > struct derived_from
>{ enum { value = is_base_and_derived< U, T >::value };
>template< typename U > struct base_of
>{ enum { value = is_base_and_derived< T, U >::value };
> };
>
> // usage:
>
> is< D >::derived_from< B >::value
> is< B >::base_of< D >::value
>
> Thoughts?
>
> Regards, Daniel
It gets ugly in the common case (where D is a template parameter):
is::template derived_from::value
Doug
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
John Maddock wrote:
>
> > I've always felt that is_base_and_derived is a funny name. is_base_of D>
> > and is_derived_from both look pronounceable(sp?) to me: "is B a base
> > of D? is D derived from B?"
> >
> > While we're at it, is the final verdict that is_base_and_derived
> > should be false? What about is_base_and_derived?
>
> The LWG suggested (and I agreed with) a change to "is_base".
I don't like this - I gave the rationale in another posting already.
Here's yet another idea which might keep the syntax readable for the
user:
// given some is_base_and_derived< B, D >::value
template< typename T > struct is
{
template< typename U > struct derived_from
{ enum { value = is_base_and_derived< U, T >::value };
template< typename U > struct base_of
{ enum { value = is_base_and_derived< T, U >::value };
};
// usage:
is< D >::derived_from< B >::value
is< B >::base_of< D >::value
Thoughts?
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: Re: is_base_and_derived question
"John Maddock" <[EMAIL PROTECTED]> writes: >> I've always felt that is_base_and_derived is a funny name. is_base_of D> >> and is_derived_from both look pronounceable(sp?) to me: "is B a base >> of D? is D derived from B?" >> > The LWG suggested (and I agreed with) a change to "is_base". Wow, how did I miss that? I find is_base_and_derived to be much clearer. With "is_base", how will I know which of the two arguments is the supposed base class? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
> Before changing the documentation please consider the following improved > implemetation that overcomes ambiguity and access control issues of the > current is_base_and_derived implemetation (I lately posted it to c.l.c++.m) That's really interesting, but I can't get to work with the compilers I have access to (Borland/gcc), I've attached a modified version that at least compiles with these compilers, but it doesn't produce the correct results: Running 1 test case... Platform: Cygwin Compiler: GNU C++ version 3.2 20020927 (prerelease) STL : GNU libstdc++ version 20020927 Boost : 1.30.0 is_base_and_derived_test.cpp(109): error in "is_base_and_derived": The expression: "(::boost::is_base_and_derived::value)" had an invalid value (found 0, expected 1) is_base_and_derived_test.cpp(110): error in "is_base_and_derived": The expression: "(::boost::is_base_and_derived::value)" had an invalid value (found 0, expected 1) is_base_and_derived_test.cpp(111): error in "is_base_and_derived": The expression: "(::boost::is_base_and_derived::value)" had an invalid value (found 0, expected 1) is_base_and_derived_test.cpp(119): error in "is_base_and_derived": The expression: "(::boost::is_base_and_derived::value)" had an invalid value (found 0, expected 1) is_base_and_derived_test.cpp(121): error in "is_base_and_derived": The expression: "(::boost::is_base_and_derived::value)" had an invalid value (found 0, expected 1) Test suite "Type Traits" failed with: 15 assertions out of 20 passed 5 assertions out of 20 failed Test case "is_base_and_derived" failed with: 15 assertions out of 20 passed 5 assertions out of 20 failed Any ideas, or results from other compilers? John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm is_base_and_derived_test.cpp Description: Binary data ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
> I've always felt that is_base_and_derived is a funny name. is_base_of > and is_derived_from both look pronounceable(sp?) to me: "is B a base > of D? is D derived from B?" > > While we're at it, is the final verdict that is_base_and_derived > should be false? What about is_base_and_derived? The LWG suggested (and I agreed with) a change to "is_base". And yes, if one or the other template arguments are non-class types, then the answer is false (I may need to double check the current implementation on this). John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
From: "Rani Sharoni" <[EMAIL PROTECTED]>
>
> I fogot to show little usability sample:
>
> struct B {};
> struct B1 : B {};
> struct B2 : B {};
> struct D : B1, private B2 {};
>
> typedef char Test[is_base_and_derived::result]; // improvement 1 -
> multiple base
> typedef char Test[is_base_and_derived::result];
> typedef char Test[is_base_and_derived::result]; // improvement 2 -
> private base
> typedef char Test[!is_base_and_derived::result];
Very clever. But I'm not sure whether this is what is_base_and_derived is
supposed to check. It seems that many are using it as
is_accessible_base_of_derived, is-a, or is_convertible.
Perhaps we need two separate metafunctions for that.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
>From: "Terje Slettebø" <[EMAIL PROTECTED]>
> >From: "Rani Sharoni" <[EMAIL PROTECTED]>
>
> > Before changing the documentation please consider the following improved
> > implemetation that overcomes ambiguity and access control issues of the
> > current is_base_and_derived implemetation (I lately posted it to
> c.l.c++.m)
> > :
> >
> > template
> > struct is_base_and_derived
> > {
> > private:
> > typedef char (&yes)[1];
> > typedef char (&no) [2];
> >
> > template
> > static yes check(D const volatile &, T);
> > static no check(B const volatile &, int);
> >
> > struct C
> > {
> > operator B const volatile &() const;
> > operator D const volatile &();
> > };
> >
> > static C getC();
> > public:
> > static const bool result =
> > sizeof(check(getC(), 0)) == sizeof(yes);
> > };
> >
> > Additional specializations needed (e.g. void and reference types)
>
> Very nice, Rani. Very clever. :)
>
> It's interesting that, according to your clc++m posting, the inspiration
of
> this came from Andrei Alexandrescu's article on Mojo, who also came up
with
> Loki's SuperSubclass trait. Dave Abrahams is also credited in the thread,
> for contributing to the above technique.
The technique the above is based on is also very clever, of course. :)
> As I understand, the reason it works for multiple occurrences of the same
> base class is that it's not asking for D's B subobject, but instead for a
> conversion to _a_ B (any B).
After I sent this I came to wonder how this works, after all, and I found
that the actual conversion done is C to D, not D to B, but the end result is
that it means D is derived from B.
In the previous posting, I didn't want to repeat the explanation given in
the Vandevoorde posting that Rani gives link to in the clc++m posting
(http://groups.google.com/groups?selm=df893da6.0301280859.522081f7%40posting
.google.com). However, as Rani's code uses the technique there, with a few
twists, I thought it could be useful to give a better explanation of its
workings than my previous posting (which was mostly a sketch, to not repeat
the mentioned posting, but thanks for the acknowledgement, Dave A.). So here
goes:
Let's take the multiple base class mentioned above, as an example, and the
following will also show why there's not a problem with ambiguous base
class:
struct B {};
struct B1 : B {};
struct B2 : B {};
struct D : B1, private B2 {};
typedef char Test[is_base_and_derived::result]; // improvement 1 -
multiple base
We have several possible conversion sequences:
For "static no check(B const volatile &, int)" we have the conversion
sequences C -> C const -> B and C -> D -> B1/B2 -> B
For "static yes check(D const volatile &, T)" we have the conversion
sequence C -> D
Since, for the purpose of selecting the appropriate user-defined conversion
for a given function, it only considers up to the user-defined conversion,
for the first function this means choosing between C -> C const and C -> C,
and it chooses the latter. Therefore, we have:
C -> D -> B1/B2 -> B
C -> D
Here, the principle of the "shortest subsequence" applies, and it chooses
C -> D. This shows that it doesn't even need to consider the multiple paths
to B, as that possibility is eliminated before it could possibly cause
ambiguity. Nifty. :)
As Daveed notes in the posting Rani gives a link to in the clc++m posting,
if D is not derived from B, it has to choose between C -> C const -> B for
the first function, and C -> D for the second function, which are just as
good, _had it not been for the fact that "static no check(B const volatile
&, int)" is not templated (as Rani points out in the posting)_, which makes
C -> C const B the best choice, resulting in "no".
Also, if C::operator B hadn't been const, the two conversion sequences for
"static no check(B const volatile &, int)" would have been ambiguous.
Regards,
Terje
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
Terje Slettebø <[EMAIL PROTECTED]> writes:
>>From: "Rani Sharoni" <[EMAIL PROTECTED]>
>
>> template
>> struct is_base_and_derived
>> {
>> private:
>> typedef char (&yes)[1];
>> typedef char (&no) [2];
>>
>> template
>> static yes check(D const volatile &, T);
>> static no check(B const volatile &, int);
>>
>> struct C
>> {
>> operator B const volatile &() const;
>> operator D const volatile &();
>> };
>>
>> static C getC();
>> public:
>> static const bool result =
>> sizeof(check(getC(), 0)) == sizeof(yes);
>> };
>>
>> Additional specializations needed (e.g. void and reference types)
>
> Very nice, Rani. Very clever. :)
I'm only not commenting yet because I don't get it yet.
> It's interesting that, according to your clc++m posting, the inspiration of
> this came from Andrei Alexandrescu's article on Mojo, who also came up with
> Loki's SuperSubclass trait. Dave Abrahams is also credited in the thread,
> for contributing to the above technique.
I don't think I deserve credit for anything above. What I did for
Mojo has to do with using derivation to force some precedence in the
overload resolution (according to rules I probably never really
understood, but had an intuitive feeling for).
> As you show in the other posting with example use, the above version works
> as overload resolution is done before access check, so it works also for
> private base classes. Besides, in this case, it never gets to do an access
> check, as the actual call is never done.
Oh, well maybe it has a remote connection to my Mojo contribution, but
that would depend on my having understood the mechanism at work (which
I clearly did not ;->).
> As I understand, the reason it works for multiple occurrences of the same
> base class is that it's not asking for D's B subobject, but instead for a
> conversion to _a_ B (any B).
>
> Also, "static no check(B const volatile &,int)" works as an ambiguity
> buster, in the case where B is not a base class of D.
Nice explanation. I'll have to look again tomorrow when I have a few
more brain cells at my disposal...
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
>From: "Rani Sharoni" <[EMAIL PROTECTED]>
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > "John Maddock" <[EMAIL PROTECTED]> writes:
> > > Yes, a class is it's own superclass/subclass, but IMO not it's own
> > > base: so it is a bug in the implementation.
> >
> > I'd like to suggest changing the documentation to match the
> > implementation at this point. I know of a few places where I have
> > relied on the current semantics, and I'm sure that's the case for
> > others as well. I'm not set on this course, but I think it's worth
> > considering.
>
> Before changing the documentation please consider the following improved
> implemetation that overcomes ambiguity and access control issues of the
> current is_base_and_derived implemetation (I lately posted it to
c.l.c++.m)
> :
>
> template
> struct is_base_and_derived
> {
> private:
> typedef char (&yes)[1];
> typedef char (&no) [2];
>
> template
> static yes check(D const volatile &, T);
> static no check(B const volatile &, int);
>
> struct C
> {
> operator B const volatile &() const;
> operator D const volatile &();
> };
>
> static C getC();
> public:
> static const bool result =
> sizeof(check(getC(), 0)) == sizeof(yes);
> };
>
> Additional specializations needed (e.g. void and reference types)
Very nice, Rani. Very clever. :)
It's interesting that, according to your clc++m posting, the inspiration of
this came from Andrei Alexandrescu's article on Mojo, who also came up with
Loki's SuperSubclass trait. Dave Abrahams is also credited in the thread,
for contributing to the above technique.
As you show in the other posting with example use, the above version works
as overload resolution is done before access check, so it works also for
private base classes. Besides, in this case, it never gets to do an access
check, as the actual call is never done.
As I understand, the reason it works for multiple occurrences of the same
base class is that it's not asking for D's B subobject, but instead for a
conversion to _a_ B (any B).
Also, "static no check(B const volatile &,int)" works as an ambiguity
buster, in the case where B is not a base class of D.
Regards,
Terje
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: is_base_and_derived question
"Rani Sharoni" <[EMAIL PROTECTED]> wrote in message
b16dqm$sh9$[EMAIL PROTECTED]">news:b16dqm$sh9$[EMAIL PROTECTED]...
>
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > "John Maddock" <[EMAIL PROTECTED]> writes:
> > > Yes, a class is it's own superclass/subclass, but IMO not it's own
> > > base: so it is a bug in the implementation.
> >
> > I'd like to suggest changing the documentation to match the
> > implementation at this point. I know of a few places where I have
> > relied on the current semantics, and I'm sure that's the case for
> > others as well. I'm not set on this course, but I think it's worth
> > considering.
>
> Before changing the documentation please consider the following improved
> implemetation that overcomes ambiguity and access control issues of the
> current is_base_and_derived implemetation (I lately posted it to
c.l.c++.m)
> :
>
> template
> struct is_base_and_derived
> {
> private:
> typedef char (&yes)[1];
> typedef char (&no) [2];
>
> template
> static yes check(D const volatile &, T);
> static no check(B const volatile &, int);
>
> struct C
> {
> operator B const volatile &() const;
> operator D const volatile &();
> };
>
> static C getC();
> public:
> static const bool result =
> sizeof(check(getC(), 0)) == sizeof(yes);
> };
>
> Additional specializations needed (e.g. void and reference types)
I fogot to show little usability sample:
struct B {};
struct B1 : B {};
struct B2 : B {};
struct D : B1, private B2 {};
typedef char Test[is_base_and_derived::result]; // improvement 1 -
multiple base
typedef char Test[is_base_and_derived::result];
typedef char Test[is_base_and_derived::result]; // improvement 2 -
private base
typedef char Test[!is_base_and_derived::result];
Enjoy,
Rani
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
"Andrei Alexandrescu" <[EMAIL PROTECTED]> writes: > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> > Yes, a class is it's own superclass/subclass, but IMO not it's own >> > base: so it is a bug in the implementation. >> >> I'd like to suggest changing the documentation to match the >> implementation at this point. I know of a few places where I have >> relied on the current semantics, and I'm sure that's the case for >> others as well. I'm not set on this course, but I think it's worth >> considering. > > At the cost of adding an extra name, maybe it would be nice to provide > is_base_and_derived and is_super_and_subclass. I could get behind that if I could quickly tell the difference in semantics from those names, but I can't. Also, I think there's a principle behind the boost type traits that they reflect standard notions of the type system, (which doesn't include "subclass"), so by that logic my idea of keeping the semantics and changing the docs also seems kinda bogus. I guess I withdraw it. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: is_base_and_derived question
Andrei Alexandrescu wrote: > > At the cost of adding an extra name, maybe it would be nice to provide > is_base_and_derived and is_super_and_subclass. I'm using is_base_and_derived_strict in my own traits. I like that "base" and "derived" reflect the parameters order, but I always mix up "super" and "sub" :-/ 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: Re: is_base_and_derived question
From: "Andrei Alexandrescu" <[EMAIL PROTECTED]> > "David Abrahams" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > Yes, a class is it's own superclass/subclass, but IMO not it's own > > > base: so it is a bug in the implementation. > > > > I'd like to suggest changing the documentation to match the > > implementation at this point. I know of a few places where I have > > relied on the current semantics, and I'm sure that's the case for > > others as well. I'm not set on this course, but I think it's worth > > considering. > > At the cost of adding an extra name, maybe it would be nice to provide > is_base_and_derived and is_super_and_subclass. I've always felt that is_base_and_derived is a funny name. is_base_of and is_derived_from both look pronounceable(sp?) to me: "is B a base of D? is D derived from B?" While we're at it, is the final verdict that is_base_and_derived should be false? What about is_base_and_derived? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: is_base_and_derived question
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > Yes, a class is it's own superclass/subclass, but IMO not it's own > > base: so it is a bug in the implementation. > > I'd like to suggest changing the documentation to match the > implementation at this point. I know of a few places where I have > relied on the current semantics, and I'm sure that's the case for > others as well. I'm not set on this course, but I think it's worth > considering. At the cost of adding an extra name, maybe it would be nice to provide is_base_and_derived and is_super_and_subclass. Andrei ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: is_base_and_derived question
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "John Maddock" <[EMAIL PROTECTED]> writes:
> > Yes, a class is it's own superclass/subclass, but IMO not it's own
> > base: so it is a bug in the implementation.
>
> I'd like to suggest changing the documentation to match the
> implementation at this point. I know of a few places where I have
> relied on the current semantics, and I'm sure that's the case for
> others as well. I'm not set on this course, but I think it's worth
> considering.
Before changing the documentation please consider the following improved
implemetation that overcomes ambiguity and access control issues of the
current is_base_and_derived implemetation (I lately posted it to c.l.c++.m)
:
template
struct is_base_and_derived
{
private:
typedef char (&yes)[1];
typedef char (&no) [2];
template
static yes check(D const volatile &, T);
static no check(B const volatile &, int);
struct C
{
operator B const volatile &() const;
operator D const volatile &();
};
static C getC();
public:
static const bool result =
sizeof(check(getC(), 0)) == sizeof(yes);
};
Additional specializations needed (e.g. void and reference types)
Cheers,
Rani
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
