Re: [boost] Re: is_base_and_derived question
From: "Gennaro Prota" <[EMAIL PROTECTED]>
> On Sat, 1 Feb 2003 20:01:15 -0800, "Eric Niebler" <[EMAIL PROTECTED]>
> wrote:
>
> >"Gennaro Prota" <[EMAIL PROTECTED]> wrote
> >>
> >> Well, then I imagine you would prefer the old semantics. Was there
> >> anybody complaining that being not enough?
> >>
> >
> >Yes, I was. A while back, I pointed out to Rani that is_base_and_derived
> >was insufficient to implement is_com_ptr, a trait I needed. In COM
> >programming, every interface inherits from IUnknown, and many COM objects
> >implement multiple interfaces. So is_base_and_derived >MyCOMObject> was almost always ambiguous.
> >
> >I was content to gripe, but Rani actually did something about it. The
new
> >behavior of is_base_and_derived is very welcome, IMO.
>
> Yes, Rani pointed out the usage for COM interfaces too, and that's a
> good one. I'm only a little perplexed about inaccessible bases,
> because the relevant example looks a little artificial; that doesn't
> mean that there aren't better examples, or that it is a good example
> but I have not understood it. As I said in another post, let's see how
> will this behave in practice. After all, boost is (also) a sort of
> test-bed for C++ libraries.
I think I have a use case for the new behavior.
When is_base_and_derived says true, this means that every object of
type D has a subobject of type B. This can be used to determine the order of
if statements in the code below:
if(dynamic_cast(p))
{
// ...
}
else if(dynamic_cast(p))
{
// ...
}
Modern C++ Design has an example of that.
The corrolaries are:
1. is_base_and_derived must be false, or the predicate won't be
antireflexive and mpl::sort won't work.
2. mpl::sort must work with a partial ordering predicate.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Sat, 1 Feb 2003 20:01:15 -0800, "Eric Niebler" <[EMAIL PROTECTED]> wrote: >"Gennaro Prota" <[EMAIL PROTECTED]> wrote >> >> Well, then I imagine you would prefer the old semantics. Was there >> anybody complaining that being not enough? >> > >Yes, I was. A while back, I pointed out to Rani that is_base_and_derived >was insufficient to implement is_com_ptr, a trait I needed. In COM >programming, every interface inherits from IUnknown, and many COM objects >implement multiple interfaces. So is_base_and_derivedMyCOMObject> was almost always ambiguous. > >I was content to gripe, but Rani actually did something about it. The new >behavior of is_base_and_derived is very welcome, IMO. Yes, Rani pointed out the usage for COM interfaces too, and that's a good one. I'm only a little perplexed about inaccessible bases, because the relevant example looks a little artificial; that doesn't mean that there aren't better examples, or that it is a good example but I have not understood it. As I said in another post, let's see how will this behave in practice. After all, boost is (also) a sort of test-bed for C++ libraries. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
"Gennaro Prota" <[EMAIL PROTECTED]> wrote > > Well, then I imagine you would prefer the old semantics. Was there > anybody complaining that being not enough? > Yes, I was. A while back, I pointed out to Rani that is_base_and_derived was insufficient to implement is_com_ptr, a trait I needed. In COM programming, every interface inherits from IUnknown, and many COM objects implement multiple interfaces. So is_base_and_derived was almost always ambiguous. I was content to gripe, but Rani actually did something about it. The new behavior of is_base_and_derived is very welcome, IMO. Eric ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Tue, 28 Jan 2003 19:41:09 +0200, "Peter Dimov" <[EMAIL PROTECTED]> wrote: >I've always felt that is_base_and_derived is a funny name. Just to have a moment of recreation before resuming work... it looks funny to me too, but for another reason. To an Italian it creates a strange effect to have "is" (singular) and the conjunction "and" between the names; off-hand one wonders: "How *is* "? Maybe they meant "*are* base and derived"? :-) However after the initial shock, I've mentally mapped it to something along the lines of is the couple (B, D) of the form (base, derived)? Not that one can really put down in words a mental association, but it's more or less something like that :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Fri, 31 Jan 2003 19:30:09 +0100, Gennaro Prota <[EMAIL PROTECTED]> wrote: > This wouldn't certainly be >a new experience for C++, since it has happened with templates or e.g. >with function call expressions as operand of sizeof. Well, I meant that 'additional' usages for templates were found, beyond the purpose they were invented for. Not that their use was found late :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Fri, 31 Jan 2003 12:14:09 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >I'd rather settle on one for the sake of simplicity and see if it's >enough for people. Once you provide two interfaces, you're sort of >stuck supporting them both. Well, then I imagine you would prefer the old semantics. Was there anybody complaining that being not enough? Maybe however it would be nice to see if we find an use for the new semantics. I don't know what it could be but probably knowing that private or ambiguous base classes are detectable without errors will encourage someone to find an use for that. This wouldn't certainly be a new experience for C++, since it has happened with templates or e.g. with function call expressions as operand of sizeof. Similarly knowing widely unknown rules about conversion ranking allowed Rani to find their application. In fact, the 'old' version is implementable in terms of the new one, but not with compilers that can't digest the latter, of course. The maintenance/supporting burden you refer to seems mainly due to broken compilers :-/ Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
>From: "Daniel Frey" <[EMAIL PROTECTED]> > David Abrahams wrote: > > > > > Who cares? The new toy is so cool! :-) Seriously, Peter is a wise man. > > > Personally I would go with his suggestion about having two (or more) > > > separate metafunctions, at least for the sake of generality > > > > I'd rather settle on one for the sake of simplicity and see if it's > > enough for people. Once you provide two interfaces, you're sort of > > stuck supporting them both. > > I agree. And we should keep in mind that people can use "trivial" > combination anyway, so we needn't offer them all with separate > names/interfaces, e.g. > >is_base_and_derived< B, D >::value || is_void< B >::value > > is easy enough for users, so if they want to use "void" as a base for > all classes, they can do it that way. All we need to do is to provide > very good documentation. This may solve the issue of how or whether to support the semantics of the current implementation. That may be something like: is_base_and_derived::value && is_convertible::value Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Fri, 31 Jan 2003 16:15:49 +0100, Terje Slettebø <[EMAIL PROTECTED]> wrote: >>From: "Gennaro Prota" <[EMAIL PROTECTED]> >> On Thu, 30 Jan 2003 15:13:19 +0100, Terje Slettebø >> <[EMAIL PROTECTED]> wrote: >> >> [...] >> >> Roughly speaking B is a base of D if and only if >> >> the base-specifier-list of D contains a class name for B or for a >> >> class of which B is a base. Of course you can see if that's the case >> >> by knowing the definition of D and examining an inheritance graph. And >> >> since that's what a compiler does all the time, is_base_and_derived is >> >> another thing that could be (ahehm) easily implemented as a built-in >> >> operator. >> > >> >True. But it's also detectable using C++98, as shown by Rani's proposal. >> >> One must be *extremely careful* when making such an assertion. > >In the following part of the posting, I said that if it turns out it doesn't >work correctly, then... Ok. But in the text above you say that it is detectable, and that Rani's proposal shows that. Then you say: if it turns out that it isn't detectable... :-) (I hope you don't mind if I joke a bit about the issue...) >> We may >> "understand" how it works and have a few test cases, but that's not a >> big guarantee. C++ is a _very_ complex language, and all sorts of >> conversions can appear wherever you expect them the less. The fact >> that we don't see any leak in Rani's code doesn't mean that it there >> isn't. Probably, a week ago we were all "enough convinced" that it >> wasn't possible to detect a private base without causing an access >> error. > >No. You can't prove a negative, an impossibility. Out of context this is a meaningless sentence. Taking it easy however, that's more-or-less what I wanted to say with the sentence that starts with "We may 'understand' how it works and have a few test cases...". You have simply repeated that and objected to the less strict part, the one that starts with "maybe...", which is rather a light comment intended, to say, to get a moral from the story. I'm used to say that if you find an error (or a flaw, or a defect) in something you can usually be reasonably sure that an error effectively exists; if you find none, than you can't say that it is error free. Note the words "usually" and "reasonably"; the first part isn't certain either (you may find an error and then realize that it isn't). That's, after all, common knowledge in scienze; as A. Einstein said with a hyperbole: No amount of experimentation can ever prove me right; a single experiment can prove me wrong >You can't prove that >something can't be done. You can, however, prove that something can be done. What you have proved that can be done? That on compiler xyz, kfg and xmn, the provided test cases give the expected result. Nothing ensures e.g. that in a more complex case it works as well. Now my last sentence is a little exaggerated, of course, but it's there to object your dangerous sentence "prove that something can be done". Such "general meaning" sentences are typical when one tries to argue his position, and all in all aren't wrong. But then the interlocutor immediately applies them to the case at hand (in this code, the code we are talking about) and "cheats" on the meaning of some words: in this case you could have cheated (or someone could have been) about the word "something", saying then that you have proved that detection of any base, accessible or not, can be done. What you have proved, instead, is that detection with the tested compilers, and with the tested cases, is possible. >You use an analogy later here, and I can come with one, as well: No matter >how many black crows you find, you can't prove that there can never be a >white crow. Only one white crow is enough to prove that there can be a white >crow. Out of curiosity: did you read Martin Gardner's books, or his Scientific American articles? >>> And if we were convinced about that and were wrong, then we >> could be wrong now by thinking that the code works. > >Like I said, I've never said that this has been _proven_. You seem to be >jumping the gun a little, here. Eheheheh... nice idiom :-) No, I wasn't jumping the gun. If you read a little back, you will see that everything started from your assertion that detecting if B is a base of D is doable "using C++98, as shown by Rani's proposal". Had you put, for instance, a "maybe" in that sentence I wouldn't have even replied. Furthermore the objection was just to that sentence; I didn't say you were arguing against built-in support. I said that the C++ 98 solution, *the one detecting ambiguous and private bases too* (if that's what we want), is almost a miracle, a latest news discovery which we still don't know well, where as the built-in solution is something so trivial to implement that it will probably take less time to the committee to specify and less time to the compiler writer to implement. > Like I said in the posting, I'm not arguing >whether or not there s
[boost] Re: is_base_and_derived question
David Abrahams wrote: > > > Who cares? The new toy is so cool! :-) Seriously, Peter is a wise man. > > Personally I would go with his suggestion about having two (or more) > > separate metafunctions, at least for the sake of generality > > I'd rather settle on one for the sake of simplicity and see if it's > enough for people. Once you provide two interfaces, you're sort of > stuck supporting them both. I agree. And we should keep in mind that people can use "trivial" combination anyway, so we needn't offer them all with separate names/interfaces, e.g. is_base_and_derived< B, D >::value || is_void< B >::value is easy enough for users, so if they want to use "void" as a base for all classes, they can do it that way. All we need to do is to provide very good documentation. 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: is_base_and_derived question
>From: "David Abrahams" <[EMAIL PROTECTED]> > Terje Slettebø <[EMAIL PROTECTED]> writes: > > > No. You can't prove a negative, an impossibility. > > I think that's wrong, and here's my one white crow to prove it ;-) > > I can prove that there can never exist a positive integral multiple of 2 which > is both greater than 2 and prime. > > It's the same as saying that *every* positive integral multiple of 2 > which is greater than 2 is a non-prime (now it's not a negative > statement anymore, but it is logically equivalent). The positive > integral multiples of 2 which are not greater than 2 are: 2. Since > every other positive integral multiple of 2 is divisible by both 2 and > itself, it must be non-prime. Ok, so you can do it in a field where you decide on all the rules, such as maths. I was more thinking in terms of if you don't have all the facts. For example, many thought it was impossible to fly, and perhaps constructed "proofs" for it, using their available knowledge. However, it turned out to be possible, anyway, in a way they may not have known about. However, since the topic was whether it was possible to prove that you could not detect inheritance without an access violation, I guess that might be provable, as well, since you may decide on the logic used in the implementation. So it seems you're right. > But anyway, isn't this straying a little bit far from being on-topic? It is. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
Gennaro Prota <[EMAIL PROTECTED]> writes: > On Fri, 31 Jan 2003 08:27:25 -0500, David Abrahams > <[EMAIL PROTECTED]> wrote: > >>S... Somewhere back in this thread Peter Dimov raised a serious >>question about whether this implements the semantics we want. Was >>there ever agreement on that? > > Who cares? The new toy is so cool! :-) Seriously, Peter is a wise man. > Personally I would go with his suggestion about having two (or more) > separate metafunctions, at least for the sake of generality I'd rather settle on one for the sake of simplicity and see if it's enough for people. Once you provide two interfaces, you're sort of stuck supporting them both. -- 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: is_base_and_derived question
Terje Slettebø <[EMAIL PROTECTED]> writes: > No. You can't prove a negative, an impossibility. I think that's wrong, and here's my one white crow to prove it ;-) I can prove that there can never exist a positive integral multiple of 2 which is both greater than 2 and prime. It's the same as saying that *every* positive integral multiple of 2 which is greater than 2 is a non-prime (now it's not a negative statement anymore, but it is logically equivalent). The positive integral multiples of 2 which are not greater than 2 are: 2. Since every other positive integral multiple of 2 is divisible by both 2 and itself, it must be non-prime. QED, or whatever it is you say while gleefully dancing on the logical grave of your vanquished opponent . But anyway, isn't this straying a little bit far from being on-topic? -- 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
[boost] Re: is_base_and_derived question
On Fri, 31 Jan 2003 08:27:25 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >S... Somewhere back in this thread Peter Dimov raised a serious >question about whether this implements the semantics we want. Was >there ever agreement on that? Who cares? The new toy is so cool! :-) Seriously, Peter is a wise man. Personally I would go with his suggestion about having two (or more) separate metafunctions, at least for the sake of generality, and to allow people to experiment with the new semantics. I hope nobody will then come out asking for is_ambiguous_and_anyway_protected_base_class<> is_ambiguous_with_at_least_one_private_base_class<> is_ambiguous_with_one_private_and_three_indirect_protected_...<> ... sigh... :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
Terje Slettebø wrote: > > You can't prove a negative, an impossibility. Can you prove 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: is_base_and_derived question
>From: "Terje Slettebø" <[EMAIL PROTECTED]> > >From: "David Abrahams" <[EMAIL PROTECTED]> > > > S... Somewhere back in this thread Peter Dimov raised a serious > > question about whether this implements the semantics we want. Was > > there ever agreement on that? > > As I mentioned in an earlier posting, Rani's proposal does what the current > docs on is_base_and_derived says. It doesn't mandate public, unambiguous > base class. If one wants that semantic, then perhaps another trait could be > useful for it. Or, change the description in the docs to reflect the semantics of the current version. Either one or the other needs to be done, I think, because as it stands, the description doesn't match the current implementation. So either we change the map, or change the terrain. :) Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
>From: "David Abrahams" <[EMAIL PROTECTED]> > "John Maddock" <[EMAIL PROTECTED]> writes: > > >> Maybe you had the following variation on Terje's code in mind. > >> > >> The following worked with GCC3.1/2, VC6/7/7.1 and Comeau 4.3.0.1: > > > > Hey, now that one really does work well, I'm still testing here (doesn't > > work with Borland, but I have a fallback position for that), but if there > > are no objections then you should expect to see the boost code updated soon. > > One question though - a lot of people seem to have worked on this: which > > people deserve the copyright/credit listing? > > S... Somewhere back in this thread Peter Dimov raised a serious > question about whether this implements the semantics we want. Was > there ever agreement on that? As I mentioned in an earlier posting, Rani's proposal does what the current docs on is_base_and_derived says. It doesn't mandate public, unambiguous base class. If one wants that semantic, then perhaps another trait could be useful for it. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
>From: "Gennaro Prota" <[EMAIL PROTECTED]> > On Thu, 30 Jan 2003 15:13:19 +0100, Terje Slettebø > <[EMAIL PROTECTED]> wrote: > > [...] > >> Roughly speaking B is a base of D if and only if > >> the base-specifier-list of D contains a class name for B or for a > >> class of which B is a base. Of course you can see if that's the case > >> by knowing the definition of D and examining an inheritance graph. And > >> since that's what a compiler does all the time, is_base_and_derived is > >> another thing that could be (ahehm) easily implemented as a built-in > >> operator. > > > >True. But it's also detectable using C++98, as shown by Rani's proposal. > > One must be *extremely careful* when making such an assertion. In the following part of the posting, I said that if it turns out it doesn't work correctly, then... > We may > "understand" how it works and have a few test cases, but that's not a > big guarantee. C++ is a _very_ complex language, and all sorts of > conversions can appear wherever you expect them the less. The fact > that we don't see any leak in Rani's code doesn't mean that it there > isn't. Probably, a week ago we were all "enough convinced" that it > wasn't possible to detect a private base without causing an access > error. No. You can't prove a negative, an impossibility. You can't prove that something can't be done. You can, however, prove that something can be done. You use an analogy later here, and I can come with one, as well: No matter how many black crows you find, you can't prove that there can never be a white crow. Only one white crow is enough to prove that there can be a white crow. > And if we were convinced about that and were wrong, then we > could be wrong now by thinking that the code works. Like I said, I've never said that this has been _proven_. You seem to be jumping the gun a little, here. Like I said in the posting, I'm not arguing whether or not there should be built-in language support for this. I've just pointed out some consequences of either approach. > Let me make a little digression: the great Adrien Marie Legendre once > "proved" that there doesn't exist any couple of rational numbers x and > y such that: > > x**3 + y**3 = 6 > > It then happened that Henry Ernest Dudeney published a solution with > only two digits in the numerator and the denominator of both > fractions: > > 17/21 and 37/21 My point exactly: Adrien Marie Legendre tried to prove a negative. > Now, you will agree with me that Legendre was all but a dumb. And he > even had a proof. As was shown with your example, this was not a logically valid proof. > If you want another example: when Whiles published > his first demonstration of the last theorem of Fermat he was sure the > proof was right, but an error was found by the reviewers. Then he made > some changes and no error has been found so far. Now, the point of > this rigmarole is not that we must proof any assertion concerning C++ > (we are programmers not mathematician) but that we must be careful and > modest; everybody makes error and the fact that experts are less > likely to make errors is just an illusion: They may be less likely to make "obvious" mistakes. This goes for any field. This is analogous to the advantages of a four-wheel drive car: It lets you get stuck in inaccessible places. :) You may drive where normal cars can't go, but if you get stuck, you may need a helicopter to get out. :) You make this point in the following, as well. > the "complexity limit" of > what you get right is just shifted a little further on: you are more > "exercised" but there's a limit (higher than the limit of a beginner) > after you are, to say, in foggy land too. In the case of Whiles, the > demonstration is so complex that not even an expert can state, with a > reasonable certainty, that it is correct. As to C++, a number of > experts certainly thought, with reasonable certainty, that the > specification was correct but then we have a list of hundreds of > defects. And some of those defects are on *fundamental* aspects of the > language. Also some of them, e.g. issue 200, are simply incredible for > their "simplicity". The fact that after 2 years it hasn't been solved > yet means that it is *too* complex, even for the committee experts. > There's no offense intended in my words. I think everybody should be > fair enough to admit that. Sometimes the committee likes to venture > out to sea, probably because they are fun of the language just like me > and you (more on this later) Genny, have I ever said that Rani's proposal has been _proven_ to work? I have not. I _explicitly_ said that it could be hard to do that, but it might be possible. What I said is that it works, i.e. we haven't found a case where it doesn't work. I have _not_ stated that this has been _proven_ to work. I know about mathematical and logical formalisms, as well, and I know there may be a long way from empirical evidence, to actual proof. This doesn't me
Re: [boost] Re: is_base_and_derived question
>From: "Gennaro Prota" <[EMAIL PROTECTED]> > --- John Maddock <[EMAIL PROTECTED]> wrote: > > One question though - a lot of people seem to have worked on this: which > > people deserve the copyright/credit listing? > > Rani only, IMO. I think so, too. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
Daniel Frey wrote: > > Cool. I modified it a bit, my version works for the GCC 3.2.1 and the > Intel 7 - with no namespace polution from 'helper': (And I just noticed it even seems to work for the GCC 2.95.x!) 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: is_base_and_derived question
Rani Sharoni wrote:
>
> Here is a weird (but working !) version:
>
> template
> struct helper
> {
> template
> static yes check(int B::*, T);
> static no check(int D::*, int);
> };
>
> // TODO: add cv-qualifiers to B and D
>
> template
> struct is_base_and_derived
> {
> struct Host
> {
> operator int D::*() const;
> operator int B::*();
> };
>
> enum { result =
> sizeof(helper::check(Host(), 0)) == sizeof(yes)
> };
> };
>
> BTW: the relevant section in the C++ standard is 13.3.3.2/4/3 (especially
> the foot note).
Cool. I modified it a bit, my version works for the GCC 3.2.1 and the
Intel 7 - with no namespace polution from 'helper':
template< typename B, typename D >
struct is_base_and_derived
{
private:
struct detail
{
template< typename T >
static yes check( int B::*, T );
static no check( int D::*, int );
struct host
{
operator int D::*() const;
operator int B::*();
};
};
public:
enum {
value = sizeof detail::check( detail::host(), 0 ) == sizeof( yes )
};
};
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: is_base_and_derived question
"John Maddock" <[EMAIL PROTECTED]> writes: >> Maybe you had the following variation on Terje's code in mind. >> >> The following worked with GCC3.1/2, VC6/7/7.1 and Comeau 4.3.0.1: > > Hey, now that one really does work well, I'm still testing here (doesn't > work with Borland, but I have a fallback position for that), but if there > are no objections then you should expect to see the boost code updated soon. > One question though - a lot of people seem to have worked on this: which > people deserve the copyright/credit listing? S... Somewhere back in this thread Peter Dimov raised a serious question about whether this implements the semantics we want. Was there ever agreement on that? -- 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: is_base_and_derived question
"John Maddock" <[EMAIL PROTECTED]> writes: >> Maybe you had the following variation on Terje's code in mind. >> >> The following worked with GCC3.1/2, VC6/7/7.1 and Comeau 4.3.0.1: > > Hey, now that one really does work well, I'm still testing here (doesn't > work with Borland, but I have a fallback position for that), but if there > are no objections then you should expect to see the boost code updated soon. > One question though - a lot of people seem to have worked on this: which > people deserve the copyright/credit listing? When you check it in, John, might I suggest you add an extensive comment about how it works? -- 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: is_base_and_derived question
--- John Maddock <[EMAIL PROTECTED]> wrote: > One question though - a lot of people seem to have worked on this: which > people deserve the copyright/credit listing? Rani only, IMO. Genny. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
> Maybe you had the following variation on Terje's code in mind. > > The following worked with GCC3.1/2, VC6/7/7.1 and Comeau 4.3.0.1: Hey, now that one really does work well, I'm still testing here (doesn't work with Borland, but I have a fallback position for that), but if there are no objections then you should expect to see the boost code updated soon. One question though - a lot of people seem to have worked on this: which people deserve the copyright/credit listing? Many thanks, John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Thu, 30 Jan 2003 18:43:19 +0100, Daniel Frey <[EMAIL PROTECTED]> wrote: >Gennaro Prota wrote: >> >> to avoid changes not forced by compiler bugs. Incidentally, I noticed >> that if you add a default argument >> >> template >> static yes check(D const volatile *, T = 0); >> static no check(B const volatile *, int = 0); >> >> and write: >> >> sizeof(checker::check( (C()) /*, 0*/ )) >> >> then ambiguity problems arise, even with Comeau 4.3.0.1. Defect in the >> standard? > >What should the compiler deduce for T? Argument type deduction doesn't >work well with default parameters. You are right. I was too heedless when looking at the compiler output: the word "ambiguous" was in `B' is an ambiguous base of `D' while I thought it was in some message referring to the function call. There were just too warning messages to distinguish the errors! :-) For the records, the warnings were about choosing C::operator const volatile D*() over C::operator const volatile B*() const for the call of no check(B const volatile *, int); > There is already a DR (IIRC) that >would allow: > >template >static yes check(D const volatile *, T = 0); > >but I don't know if any compilers implement it yet. Yes, it's the very same DR that requires introduction of default template arguments for function templates: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#226 Thanks, Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
--- Peter Dimov <[EMAIL PROTECTED]> wrote:
> From: "Gennaro Prota" <[EMAIL PROTECTED]>
> > On Thu, 30 Jan 2003 10:19:53 -0500, David Abrahams
> > <[EMAIL PROTECTED]> wrote:
> >
> > >Peter D. has effectively argued in the past that void *is* a supertype
> > >of everything (well, every object type, as opposed e.g. to
> > >function/function pointer types). Given the foregoing discussion
> > >about squares and rectangles it may be the *only* supertype that we
> > >can detect with certainty.
> >
> > And since Peter D. is not in the habit of making trivial errors, this
> > makes me wonder in fact what definition of "supertype" he was
> > considering.
>
> The practical one. I.e. if you use is_base_and_derived somewhere, do
> you want "true" for B=void, if B can be void?
Ah, ok. So you've not argued that void is a supertype, just that you want the
template, conventionally, to yield void in such a case. Then you can always add
a level of indirection:
template
struct is_base_and_derived {
/* "normal meaning" implementation */
};
template
struct extended_is_base_and_derived {
static const bool value = is_base_and_derived::value;
};
template
struct extended_is_base_and_derived {
static const bool value = true;
};
> For example, if you write a class template X that is supposed to only
> operate on types derived from T (e.g. an inheritance-bounded variant), how
> would you denote the unbounded case?
>
> A related question would be: if you had common_base::type, what would
> you want returned when X and Y have no common base?
Yes, that's a little trickier. Basically, if you choose to yield an error when
X and Y have no common base than you can't simply wrap it as above. However if
you, for instance, encapsulate the have_common_base<> logic then it's easy.
Genny.
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
From: "Gennaro Prota" <[EMAIL PROTECTED]> > On Thu, 30 Jan 2003 10:19:53 -0500, David Abrahams > <[EMAIL PROTECTED]> wrote: > > >Peter D. has effectively argued in the past that void *is* a supertype > >of everything (well, every object type, as opposed e.g. to > >function/function pointer types). Given the foregoing discussion > >about squares and rectangles it may be the *only* supertype that we > >can detect with certainty. > > And since Peter D. is not in the habit of making trivial errors, this > makes me wonder in fact what definition of "supertype" he was > considering. The practical one. I.e. if you use is_base_and_derived somewhere, do you want "true" for B=void, if B can be void? For example, if you write a class template X that is supposed to only operate on types derived from T (e.g. an inheritance-bounded variant), how would you denote the unbounded case? A related question would be: if you had common_base::type, what would you want returned when X and Y have no common base? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Thu, 30 Jan 2003 10:19:53 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >Peter D. has effectively argued in the past that void *is* a supertype >of everything (well, every object type, as opposed e.g. to >function/function pointer types). Given the foregoing discussion >about squares and rectangles it may be the *only* supertype that we >can detect with certainty. And since Peter D. is not in the habit of making trivial errors, this makes me wonder in fact what definition of "supertype" he was considering. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Thu, 30 Jan 2003 15:13:19 +0100, Terje Slettebø
<[EMAIL PROTECTED]> wrote:
[...]
>> Roughly speaking B is a base of D if and only if
>> the base-specifier-list of D contains a class name for B or for a
>> class of which B is a base. Of course you can see if that's the case
>> by knowing the definition of D and examining an inheritance graph. And
>> since that's what a compiler does all the time, is_base_and_derived is
>> another thing that could be (ahehm) easily implemented as a built-in
>> operator.
>
>True. But it's also detectable using C++98, as shown by Rani's proposal.
One must be *extremely careful* when making such an assertion. We may
"understand" how it works and have a few test cases, but that's not a
big guarantee. C++ is a _very_ complex language, and all sorts of
conversions can appear wherever you expect them the less. The fact
that we don't see any leak in Rani's code doesn't mean that it there
isn't. Probably, a week ago we were all "enough convinced" that it
wasn't possible to detect a private base without causing an access
error. And if we were convinced about that and were wrong, then we
could be wrong now by thinking that the code works.
Let me make a little digression: the great Adrien Marie Legendre once
"proved" that there doesn't exist any couple of rational numbers x and
y such that:
x**3 + y**3 = 6
It then happened that Henry Ernest Dudeney published a solution with
only two digits in the numerator and the denominator of both
fractions:
17/21 and 37/21
Now, you will agree with me that Legendre was all but a dumb. And he
even had a proof. If you want another example: when Whiles published
his first demonstration of the last theorem of Fermat he was sure the
proof was right, but an error was found by the reviewers. Then he made
some changes and no error has been found so far. Now, the point of
this rigmarole is not that we must proof any assertion concerning C++
(we are programmers not mathematician) but that we must be careful and
modest; everybody makes error and the fact that experts are less
likely to make errors is just an illusion: the "complexity limit" of
what you get right is just shifted a little further on: you are more
"exercised" but there's a limit (higher than the limit of a beginner)
after you are, to say, in foggy land too. In the case of Whiles, the
demonstration is so complex that not even an expert can state, with a
reasonable certainty, that it is correct. As to C++, a number of
experts certainly thought, with reasonable certainty, that the
specification was correct but then we have a list of hundreds of
defects. And some of those defects are on *fundamental* aspects of the
language. Also some of them, e.g. issue 200, are simply incredible for
their "simplicity". The fact that after 2 years it hasn't been solved
yet means that it is *too* complex, even for the committee experts.
There's no offense intended in my words. I think everybody should be
fair enough to admit that. Sometimes the committee likes to venture
out to sea, probably because they are fun of the language just like me
and you (more on this later)
>>> Not that I'm set for it, but please think about this: can
>> you give off-hand a proof that Rani's implementation is equivalent to
>> the mechanical definition I gave above?
>
>A proof? Egads. :) I had a hard enough time figuring out how it works, in
>the first place. :)
So would you trust that code? Would you write it for a client? Note
that this is not an accuse to the code. I like it, and I agree that
Rani has been very clever to find it out, that's not the point. Also,
my remark is somewhat more general than specifically addressed to that
code.
[...]
>There are a few observations:
>
>- is_base_and_derived (Rani's proposal) is usable here and now, so
>regardless of any language/library change, it may be used now.
Indeed. But I'm seeing that then much of the things we use here are
being proposed for standardization. That's a different matter. When
you put them in the language, you will have them forever; so better
being sure they work. Otherwise I prefer just having them into boost:
after all that's "standard enough", don't you agree?
>- If it turns out that is_base_and_derived doesn't completely detect base
>and derived class, according to the definition in the standard, and a way is
>not found to do so within the current definition of the language, one may
>e.g.:
> - Change the part of the standard that the is_base_and_derived relies on
>for its workings, so that it _does_ work correctly, if possible. Or,
> - Add is_base_and_derived as an operator in C++0x
The first thing that I've thought when seeing is_base_and_derived<>
was: how would I implement it if I were a compiler writer? The answer
(in my mind) was:
template
struct is_base_and_derived {
static const bool value = __built_in_is_base_and_derived::value;
};
Simple and easy. No need to rely on strange overloading and conversion
ranking rules that, then
Re: [boost] Re: is_base_and_derived question
Gennaro Prota wrote: > > to avoid changes not forced by compiler bugs. Incidentally, I noticed > that if you add a default argument > > template > static yes check(D const volatile *, T = 0); > static no check(B const volatile *, int = 0); > > and write: > > sizeof(checker::check( (C()) /*, 0*/ )) > > then ambiguity problems arise, even with Comeau 4.3.0.1. Defect in the > standard? What should the compiler deduce for T? Argument type deduction doesn't work well with default parameters. There is already a DR (IIRC) that would allow: template static yes check(D const volatile *, T = 0); but I don't know if any compilers implement it yet. 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: is_base_and_derived question
On Thu, 30 Jan 2003 16:34:44 +0200, "Rani Sharoni"
<[EMAIL PROTECTED]> wrote:
>
>"Gennaro Prota" <[EMAIL PROTECTED]> wrote in message
>> John, unfortunately I have to turn off my computer now. I had just
>> hacked up a version that seems to work with gcc, but I don't want to
>> post it before a better testing. I'll let you know in the morning.
>
>Maybe you had the following variation on Terje's code in mind.
Yes! Not in mind, just in my editor though :-)
>The following worked with GCC3.1/2, VC6/7/7.1 and Comeau 4.3.0.1:
>
>
>typedef char (&yes)[1];
>typedef char (&no) [2];
>
>template
>struct helper
>{
>template
>static yes check(D const volatile *, T);
>static no check(B const volatile *, int);
>};
>
>template
>struct is_base_and_derived
>{
>struct Host
>{
>operator B const volatile *() const;
>operator D const volatile *();
>};
>
>enum { result =
>sizeof(helper::check(Host(), 0)) == sizeof(yes)
>};
>};
>
My version was only slightly different:
template
struct checker {
typedef char yes;
typedef char(&no)[2];
template
static yes check(D const volatile *, T);
static no check(B const volatile *, int);
};
template
struct is_base_and_derived
{
struct C
{
operator B const volatile *() const;
operator D const volatile *();
};
public:
static const bool result =
sizeof(checker::check( C() , 0 )) ==
sizeof(typename checker::yes);
};
Of course moving yes and no outside checker<> is cleaner, but I tried
to avoid changes not forced by compiler bugs. Incidentally, I noticed
that if you add a default argument
template
static yes check(D const volatile *, T = 0);
static no check(B const volatile *, int = 0);
and write:
sizeof(checker::check( (C()) /*, 0*/ ))
then ambiguity problems arise, even with Comeau 4.3.0.1. Defect in the
standard?
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
>From: "Rani Sharoni" <[EMAIL PROTECTED]> > "Gennaro Prota" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > John, unfortunately I have to turn off my computer now. I had just > > hacked up a version that seems to work with gcc, but I don't want to > > post it before a better testing. I'll let you know in the morning. > > Maybe you had the following variation on Terje's code in mind. > > The following worked with GCC3.1/2, VC6/7/7.1 and Comeau 4.3.0.1: Interesting. Just small changes in the code, like moving a struct from one template to the other, makes a dramatic difference to some compilers. However, the tests in the original posting, using array of size 0, didn't detect the problem on these compilers. Now it even works for private/protected, multiple base classes, and virtual base classes. Great. :) Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
Gennaro Prota <[EMAIL PROTECTED]> writes: > Actually the reason for my question is a little strange :-) I hope to > explain it in understandable English: Andrej said > > "void is hardly a supertype of everything" > > > Rewording it, it is: "void is not a supertype of everything". > > This immediately made me think to why he didn't say: "not a supertype > of anything". In other words I wondered: "is he implying that void is > not a supertype of everything but *is* a supertype of something"? What > it this "something"? :-) That's an example of my odd mental > contortions. Peter D. has effectively argued in the past that void *is* a supertype of everything (well, every object type, as opposed e.g. to function/function pointer types). Given the foregoing discussion about squares and rectangles it may be the *only* supertype that we can detect with certainty. -- 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
[boost] Re: is_base_and_derived question
"Rani Sharoni" <[EMAIL PROTECTED]> wrote in message
b1bd2p$i97$[EMAIL PROTECTED]">news:b1bd2p$i97$[EMAIL PROTECTED]...
>
> "Gennaro Prota" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > On Thu, 30 Jan 2003 12:38:36 -, "John Maddock"
> > <[EMAIL PROTECTED]> wrote:
> >
> > >Except it *doesn't work* !
> > >
> >
> > John, unfortunately I have to turn off my computer now. I had just
> > hacked up a version that seems to work with gcc, but I don't want to
> > post it before a better testing. I'll let you know in the morning.
>
> Maybe you had the following variation on Terje's code in mind.
>
> The following worked with GCC3.1/2, VC6/7/7.1 and Comeau 4.3.0.1:
>
>
> typedef char (&yes)[1];
> typedef char (&no) [2];
>
> template
> struct helper
> {
> template
> static yes check(D const volatile *, T);
> static no check(B const volatile *, int);
> };
>
> template
> struct is_base_and_derived
> {
> struct Host
> {
> operator B const volatile *() const;
> operator D const volatile *();
> };
>
> enum { result =
> sizeof(helper::check(Host(), 0)) == sizeof(yes)
> };
> };
Here is a weird (but working !) version:
template
struct helper
{
template
static yes check(int B::*, T);
static no check(int D::*, int);
};
// TODO: add cv-qualifiers to B and D
template
struct is_base_and_derived
{
struct Host
{
operator int D::*() const;
operator int B::*();
};
enum { result =
sizeof(helper::check(Host(), 0)) == sizeof(yes)
};
};
BTW: the relevant section in the C++ standard is 13.3.3.2/4/3 (especially
the foot note).
Cheers,
Rani
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
"Gennaro Prota" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> On Thu, 30 Jan 2003 12:38:36 -, "John Maddock"
> <[EMAIL PROTECTED]> wrote:
>
> >Except it *doesn't work* !
> >
>
> John, unfortunately I have to turn off my computer now. I had just
> hacked up a version that seems to work with gcc, but I don't want to
> post it before a better testing. I'll let you know in the morning.
Maybe you had the following variation on Terje's code in mind.
The following worked with GCC3.1/2, VC6/7/7.1 and Comeau 4.3.0.1:
typedef char (&yes)[1];
typedef char (&no) [2];
template
struct helper
{
template
static yes check(D const volatile *, T);
static no check(B const volatile *, int);
};
template
struct is_base_and_derived
{
struct Host
{
operator B const volatile *() const;
operator D const volatile *();
};
enum { result =
sizeof(helper::check(Host(), 0)) == sizeof(yes)
};
};
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 {};
typedef char TestA[is_base_and_derived::result ? 1 : -1]; // Multiple
bases
typedef char TestB[is_base_and_derived::result ? 1 : -1];
typedef char TestC[is_base_and_derived::result ? 1 : -1]; // Private
base
typedef char TestD[!is_base_and_derived::result ? 1 : -1];
typedef char TestF[is_base_and_derived::result ? 1 : -1]; // Virtual
base
// VC6/7 BUG.
// typedef char Test[!is_base_and_derived::result ? 1 : -1];
Cheers,
Rani
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
>From: "Gennaro Prota" <[EMAIL PROTECTED]> > On Thu, 30 Jan 2003 12:33:04 +0100, Terje Slettebø > <[EMAIL PROTECTED]> wrote: > > >>From: "Andrei Alexandrescu" <[EMAIL PROTECTED]> > >> Even if we also define is_super_and_subtype, > >> void is hardly a supertype of everything. > > > >Well, it could be. It's like an "abstract base class", even for built-in > >types - everything can be implicitly converted to void > > What do you mean? In standard terminology, for an expression e to be > *implicitly* convertible to T you must be able to write: > > T t = e; You're right that it isn't implicitly convertible to void in this sense. What I was thinking of was that if you return a value from a function, it may be ignored by the caller. However, you're right that this doesn't have anything to do with implicit conversion - there can't even be a void object, so it clearly isn't obeying LSP. void *, with regard to other pointers, is something else, though. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
>From: "Gennaro Prota" <[EMAIL PROTECTED]> > On Thu, 30 Jan 2003 11:13:23 +0100, Terje Slettebø > <[EMAIL PROTECTED]> wrote: > > >>From: "Gennaro Prota" <[EMAIL PROTECTED]> > > > >> On Tue, 28 Jan 2003 10:47:52 -0800, "Andrei Alexandrescu" > >> <[EMAIL PROTECTED]> wrote: > >> > >> >"Peter Dimov" <[EMAIL PROTECTED]> wrote in message > >> >> While we're at it, is the final verdict that is_base_and_derived >X> > >> >> should be false? What about is_base_and_derived? > >> > > >> >Well, clearly void is no base. Even if we also define > >is_super_and_subtype, > >> >void is hardly a supertype of everything. > >> > >> Could you please clarify this? You mean: > >> > >> T is a subtype of U <=> ...?... > >> > >> T is a supertype of U <=> ...?... > > > >Supertype/subtype is a more general notion than inheritance and > >base/derived. The Liskov Substitution Principle states[...] > > Be careful though. If you bring in a "behavioral" principle like LSP > than the issue becomes complicated. The point is that if you define supertype = base class and subtype = derived class, then what's the point in having an is_super_and_subtype? In this case, they would be identical. > The square/rectangle example is > classic: if your square class throws e.g. when detecting that > invariants are broken then it's trivial to construct an object of type > square o1 and a program P defined in terms of rectangles which changes > behavior if you replace an instance of rectangle with o1. Whether > defining such a square class is good practice or not is another > matter. The point is that is_base_of is just a mechanical relation > that is difficult to define in terms of behavior. Yes, as you say, the language doesn't enforce LSP for public inheritance, it merely _assumes_ it, as I mentioned in the previous posting. > Roughly speaking B is a base of D if and only if > the base-specifier-list of D contains a class name for B or for a > class of which B is a base. Of course you can see if that's the case > by knowing the definition of D and examining an inheritance graph. And > since that's what a compiler does all the time, is_base_and_derived is > another thing that could be (ahehm) easily implemented as a built-in > operator. True. But it's also detectable using C++98, as shown by Rani's proposal. > Not that I'm set for it, but please think about this: can > you give off-hand a proof that Rani's implementation is equivalent to > the mechanical definition I gave above? A proof? Egads. :) I had a hard enough time figuring out how it works, in the first place. :) It relies on some dusty corners of the language, such as the order in which overload resolution is done. As has been shown with tests, hardly any of the current compilers gets it right, only the EDG ones have been reported as working with it. I think it may be doable, though. > If you are going to write the > documentation for is_base_and_derived what do you write? The > definition above? Or something else? If you write the definition above > (as it is now, because the docs say more-or-less "if and only if B is > a base of D") shouldn't you prove that it is implementable in C++? How > much time will the committee spend to get agreement on the definition > and seeing that it is implementable? How much time does it take to > implement the built-in operator once you stick to the "mechanical" > definition? Maybe the answer to the last question is much much smaller > than the previous ones. I haven't argued for or against having is_base_and_derived as a built-in operator, or not. However, the fact is that having it as an operator requires a language change, and that's likely several years away. There are a few observations: - is_base_and_derived (Rani's proposal) is usable here and now, so regardless of any language/library change, it may be used now. - If it turns out that is_base_and_derived doesn't completely detect base and derived class, according to the definition in the standard, and a way is not found to do so within the current definition of the language, one may e.g.: - Change the part of the standard that the is_base_and_derived relies on for its workings, so that it _does_ work correctly, if possible. Or, - Add is_base_and_derived as an operator in C++0x There is a very important point: Adding is_base_and_derived as an operator/keyword in C++ requires adding a keyword, and that's a _major_ change. It may break a lot of programs, if those programs uses an identifier with this name, especially if it's not used in the way an operator would be used. On the other hand, if you're able to implement it using the language features, then it may e.g. be a standard library component, and that won't break any existing programs. > >>"What is wanted here is something like the following substitution property: > >If for each object o1 of type S there is an object o2 of type T such that > >for all programs P defined in terms of T, the behavior of P is unchanged > >when o1 is su
[boost] Re: is_base_and_derived question
"Terje Slettebø" <[EMAIL PROTECTED]> wrote in message
05e001c2c7b8$ebb14b50$cb6c6f50@pc">news:05e001c2c7b8$ebb14b50$cb6c6f50@pc...
>
> 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;
> };
>
Ironically this specialization has the same behavior as the primary
template.
Rani
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
"Daniel Frey" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > > Compiler: GNU C++ version 3.2 20020927 (prerelease)
> I also tried the GCC 3.2.1, but without success. It compiles, but it
> gives the wrong results.
> > > Any ideas, or results from other compilers?
>AFAICS the Intel 7 works fine.
> > I was able to complie the attached code (with minor improvment) using
strict
> > Comeau and VC7.1 and boost 1.29.0.
> One point about the implementation: The getC()-function isn't necessary,
Silly me. It seems that I got used to that function.
The following complied with VC6, VC7, VC7.1 and Comeau:
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 Host
{
operator B const volatile *() const;
operator D const volatile *();
};
public:
enum { result = sizeof(check(Host(), 0)) == sizeof(yes) };
};
struct B {};
struct B1 : B {};
struct B2 : B {};
struct D : B1, private B2 {};
typedef char Test[is_base_and_derived::result];
typedef char Test[is_base_and_derived::result];
typedef char Test[is_base_and_derived::result];
typedef char Test[!is_base_and_derived::result];
// Caveat VC6/7 BUG -
// typedef char Test[!is_base_and_derived::result];
I was able to complie the following code using GCC 3.1 which proves that GCC
knows the required rules:
template
long *f(D*, T);
char *f(B*, int);
struct Host1 {
operator B*() const;
operator D*();
};
long *x1 = f(Host1(), 0);
template
long *g(B2*, T);
char *g(B1*, int);
struct Host2 {
operator B1*() const;
operator B2*();
};
char *x2 = g(Host2(), 0);
BCC 5.6 selected the wrong function (x1) which proves that it disagree about
the basic rules.
Rani
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Thu, 30 Jan 2003 12:38:36 -, "John Maddock" <[EMAIL PROTECTED]> wrote: >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, unfortunately I have to turn off my computer now. I had just hacked up a version that seems to work with gcc, but I don't want to post it before a better testing. I'll let you know in the morning. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
> > Any ideas, or results from other compilers? >AFAICS the Intel 7 works fine. Thanks. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Thu, 30 Jan 2003 12:33:04 +0100, Terje Slettebø <[EMAIL PROTECTED]> wrote: >>From: "Andrei Alexandrescu" <[EMAIL PROTECTED]> >> Even if we also define is_super_and_subtype, >> void is hardly a supertype of everything. > >Well, it could be. It's like an "abstract base class", even for built-in >types - everything can be implicitly converted to void What do you mean? In standard terminology, for an expression e to be *implicitly* convertible to T you must be able to write: T t = e; Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Thu, 30 Jan 2003 11:13:23 +0100, Terje Slettebø
<[EMAIL PROTECTED]> wrote:
>>From: "Gennaro Prota" <[EMAIL PROTECTED]>
>
>> On Tue, 28 Jan 2003 10:47:52 -0800, "Andrei Alexandrescu"
>> <[EMAIL PROTECTED]> wrote:
>>
>> >"Peter Dimov" <[EMAIL PROTECTED]> wrote in message
>> >> While we're at it, is the final verdict that is_base_and_derivedX>
>> >> should be false? What about is_base_and_derived?
>> >
>> >Well, clearly void is no base. Even if we also define
>is_super_and_subtype,
>> >void is hardly a supertype of everything.
>>
>> Could you please clarify this? You mean:
>>
>> T is a subtype of U <=> ...?...
>>
>> T is a supertype of U <=> ...?...
>
>Supertype/subtype is a more general notion than inheritance and
>base/derived. The Liskov Substitution Principle states[...]
Be careful though. If you bring in a "behavioral" principle like LSP
than the issue becomes complicated. The square/rectangle example is
classic: if your square class throws e.g. when detecting that
invariants are broken then it's trivial to construct an object of type
square o1 and a program P defined in terms of rectangles which changes
behavior if you replace an instance of rectangle with o1. Whether
defining such a square class is good practice or not is another
matter. The point is that is_base_of is just a mechanical relation
that is difficult to define in terms of behavior. Putting it
differently, that's why inheritance can be misused in C++: it's up to
you to ensure a "match" between the substitutability definition and
the mechanical one. Roughly speaking B is a base of D if and only if
the base-specifier-list of D contains a class name for B or for a
class of which B is a base. Of course you can see if that's the case
by knowing the definition of D and examining an inheritance graph. And
since that's what a compiler does all the time, is_base_and_derived is
another thing that could be (ahehm) easily implemented as a built-in
operator. Not that I'm set for it, but please think about this: can
you give off-hand a proof that Rani's implementation is equivalent to
the mechanical definition I gave above? If you are going to write the
documentation for is_base_and_derived what do you write? The
definition above? Or something else? If you write the definition above
(as it is now, because the docs say more-or-less "if and only if B is
a base of D") shouldn't you prove that it is implementable in C++? How
much time will the committee spend to get agreement on the definition
and seeing that it is implementable? How much time does it take to
implement the built-in operator once you stick to the "mechanical"
definition? Maybe the answer to the last question is much much smaller
than the previous ones.
>>"What is wanted here is something like the following substitution property:
>If for each object o1 of type S there is an object o2 of type T such that
>for all programs P defined in terms of T, the behavior of P is unchanged
>when o1 is substituted for o2 then S is a subtype of T."
>
>Notice that it doesn't say anything about "class" or "inheritance",
>anywhere. If S = T, LSP still holds. Therefore, as Andrei said it, in
>language theory, such as this, a type may be considered its own
>supertype/subtype.
Actually the reason for my question is a little strange :-) I hope to
explain it in understandable English: Andrej said
"void is hardly a supertype of everything"
Rewording it, it is: "void is not a supertype of everything".
This immediately made me think to why he didn't say: "not a supertype
of anything". In other words I wondered: "is he implying that void is
not a supertype of everything but *is* a supertype of something"? What
it this "something"? :-) That's an example of my odd mental
contortions.
>Supertype/subtype may also have other forms than inheritance. "short" may be
>considered a subtype of "int"
I don't know. The LSP definition seems to elementary to me to map to
C++. Think e.g. to binding an int to a reference to int&.
int main() {
int i;
int & r = i;
}
Can you replace "int i;" with "short i;"?
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
>From: "Terje Slettebø" <[EMAIL PROTECTED]> > Given that supertype/subtype has such a general meaning, how should an > is_super_and_subtype be defined? I guess the proposal mean to define it in > terms of inheritance, only, and in that case, it would work like > is_base_and_derived, with the addition that a type is its own > supertype/subtype (but not its own base/derived type). If we consider substitutability outside the class hierarchy, only (not considering private/protected inheritance), then for is_super_and_subtype to obey LSP, it should only give true in the case where an object or pointer/reference of a type S is implicitly convertible to type T. This means public, unambiguous base class, only. This is the way is_base_and_derived works today, except that it doesn't give true for B = D. However, for is_base_and_derived to really tell if something is base and derived classes, it should ignore issues of access and ambiguity, which is related to convertibility/substitutability, only, but not to whether or not they are related by inheritance. In other words, it should give the semantic that Rani's proposal has. Whether or not the above semantic is desirable is another question. However, if it is, to summarise, we could define these like this: - Rename the current is_base_and_derived to is_super_and_subtype, and allow it to give true for S = T. - Use Rani's proposal for the new is_base_and_derived. Add specialisation to give false for B = D. There's also a question of existing code relying on the current semantics, of is_base_and_derived giving false in the case of private/protected or ambiguous base class. However, it may be argued that such code does not rely on the stated documentation, so it's broken, anyway. Changing the implementation of is_base_and_derived to use Rani's proposal still gives its stated semantics, which is (from the docs): is_base_and_derived::value - Evaluates to true if type T is a base class to type U. It does not say "public, unambiguous base". That could be the wording for is_super_and_subtype, instead. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
>From: "Gennaro Prota" <[EMAIL PROTECTED]> > On Tue, 28 Jan 2003 10:47:52 -0800, "Andrei Alexandrescu" > <[EMAIL PROTECTED]> wrote: > > >"Peter Dimov" <[EMAIL PROTECTED]> wrote in message > >> While we're at it, is the final verdict that is_base_and_derived > >> should be false? What about is_base_and_derived? > > > >Well, clearly void is no base. Even if we also define is_super_and_subtype, > >void is hardly a supertype of everything. > > Could you please clarify this? You mean: > > T is a subtype of U <=> ...?... > > T is a supertype of U <=> ...?... Supertype/subtype is a more general notion than inheritance and base/derived. The Liskov Substitution Principle states: "What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T." Notice that it doesn't say anything about "class" or "inheritance", anywhere. If S = T, LSP still holds. Therefore, as Andrei said it, in language theory, such as this, a type may be considered its own supertype/subtype. Supertype/subtype may also have other forms than inheritance. "short" may be considered a subtype of "int", for example (the opposite may or may not be true, depending on if they are of equal size). Likewise, as Kevlin Henney noted in an article (http://www.cuj.com/experts/1901/henney.htm), a class's "const" interface may be considered a subtype of the whole interface. Notice that, as Kevlin notes in the article, for all these cases, LSP is expected by the language: A derived object or pointer/reference is implicitly converted to a Base object or pointer/reference (but going the other way requires a cast), short is convertible to int (and vice versa, in this case), and an object or pointer/reference to an object is implicitly converted to a const object or pointer/reference (but again, going the other way requires a cast). Given that supertype/subtype has such a general meaning, how should an is_super_and_subtype be defined? I guess the proposal mean to define it in terms of inheritance, only, and in that case, it would work like is_base_and_derived, with the addition that a type is its own supertype/subtype (but not its own base/derived type). This is also reflected in Loki: SuperSubclass is like is_super_and_subtype, and SuperSubclassStrict is like is_base_and_derived. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Tue, 28 Jan 2003 10:47:52 -0800, "Andrei Alexandrescu" <[EMAIL PROTECTED]> wrote: >"Peter Dimov" <[EMAIL PROTECTED]> wrote in message >> While we're at it, is the final verdict that is_base_and_derived >> should be false? What about is_base_and_derived? > >Well, clearly void is no base. Even if we also define is_super_and_subtype, >void is hardly a supertype of everything. Could you please clarify this? You mean: T is a subtype of U <=> ...?... T is a supertype of U <=> ...?... Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
Rani Sharoni wrote: > > > Compiler: GNU C++ version 3.2 20020927 (prerelease) I also tried the GCC 3.2.1, but without success. It compiles, but it gives the wrong results. > > Any ideas, or results from other compilers? AFAICS the Intel 7 works fine. > I was able to complie the attached code (with minor improvment) using strict > Comeau and VC7.1 and boost 1.29.0. One point about the implementation: The getC()-function isn't necessary, as you are in control of the class C, you know it has an accessible default ctor and thus you can call check(C()) directly. I don't know if there are any compilers which might benefit from that (I actually doubt it), but anyway... 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: is_base_and_derived question
"John Maddock" <[EMAIL PROTECTED]> wrote in message
014601c2c79c$f53f7f00$8e3687d9@1016031671">news:014601c2c79c$f53f7f00$8e3687d9@1016031671...
> > 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
> [...]
> 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?
I tried to complie the code you attached (with boost 1.29.0) but some files
were missing (test.hpp, check_integral_constant.hpp,
TYPE_TRAITS(is_base_and_derived)).
As mentioned in the c.l.c++.m posting (http://tinyurl.com/51a5) I complied
the original code with Comeau C/C++ 4.3.0.1 and VC7.1 beta.
I was able to complie the attached code (with minor improvment) using strict
Comeau and VC7.1 and boost 1.29.0.
Rani
begin 666 is_base_and_derived2.hpp
M#0HO+R H0RD@0V]P>7)I9VAT(%-T979E($-L96%R>2P@0F5M86X@1&%W97,L
M($AO=V%R9"!(:6YN86YT("8@2F]H;B!-861D;V-K(#(P,# N#0HO+R!097)M
M:7-S:6]N('1O(&-O<'DL('5S92P@;6]D:69Y+"!S96QL(&%N9"!D:7-T7)I9VAT(&YO=&EC92!A<'!E87)S(&EN(&%L;"!C;W!I97,N(%1H
M:7,@2!F;W(@86YY('!U7!E7W1R86ETPT*#0IT96UP
M;&%T92 \='EP96YA;64@0F%S92P@='EP96YA;64@1&5R:79E9#X-"G-T7!E('EE7!E9&5F(#HZ8F]O7!E("!N
M;SL-"@T*(" @('1E;7!L871E/'1Y<&5N86UE(%0^#0H@(" @65S*0T*(" @("D[#0I].PT*#0IT96UP;&%T92 \='EP96YA;64@0F%S
M92P@='EP96YA;64@1&5R:79E9#X-"G-T7!E;F%M92!"87-E+'1Y<&5N86UE($1E7!E;F%M92!$97)I=F5D
M+&ES7V)AWT[#0IS=')U8W0@0C(@.B!"('M].PT*7!E9&5F(&-H87(@5&5S=%LA:7-?8F%S95]A;F1?9&5R:79E9#Q$
6+$0^.CIV86QU95T[#0H-"BHO#0H-"@``
`
end
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
"Gennaro Prota" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > On Tue, 28 Jan 2003 03:06:35 -0800, "Andrei Alexandrescu" > <[EMAIL PROTECTED]> wrote: > > >"Thomas Witt" <[EMAIL PROTECTED]> wrote in message > >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >> IIUC is_based_and_derived evaluates to true as well. Is a class T > >> strictly speaking a base class of itself? > > > >Yes > > That's a convention of is_base_and_derived though. To the standard a > class is not a base of itself, so this convention should be > documented. In other words, you have to specify whether the ordering > is strict or not. True. I'd just note that in language theory, a type is always considered its own supertype because that makes it much easier to reason everywhere else. Andrei ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
"John Maddock" <[EMAIL PROTECTED]> writes: >> >"Thomas Witt" <[EMAIL PROTECTED]> wrote in message >> >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> >> IIUC is_based_and_derived evaluates to true as well. Is a class T >> >> strictly speaking a base class of itself? >> > >> >Yes >> >> That's a convention of is_base_and_derived though. To the standard a >> class is not a base of itself, so this convention should be >> documented. In other words, you have to specify whether the ordering >> is strict or not. > > 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. -- 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: is_base_and_derived question
--- John Maddock <[EMAIL PROTECTED]> wrote:
> > Incidentally, I've noticed that boost's implementation of
> > is_base_and_derived has the same access-checking problems as
> > is_convertible. That could be easily fixed, as said in the thread
> > about is convertible, by using function templates:
> >
> >
> > typedef char (&no_type)[1];
> > typedef char (&yes_type)[2];
> >
> > template
> > struct identity { typedef T type; };
> >
> > template
> > no_type is_convertible(...);
> >
> > template
> > yes_type is_convertible(typename identity::type);
>
> IMO your identity template only serves to trip up less capable compilers, it
> does nothing to solve member access problems.
It's there just to force explicit specification of the target type. Yes, it has
nothing to with the main topic of this discussion so you can cut it away if you
find that convenient.
Genny.
__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_base_and_derived question
> >"Thomas Witt" <[EMAIL PROTECTED]> wrote in message
> >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> >> IIUC is_based_and_derived evaluates to true as well. Is a class T
> >> strictly speaking a base class of itself?
> >
> >Yes
>
> That's a convention of is_base_and_derived though. To the standard a
> class is not a base of itself, so this convention should be
> documented. In other words, you have to specify whether the ordering
> is strict or not.
Yes, a class is it's own superclass/subclass, but IMO not it's own base: so
it is a bug in the implementation.
> Incidentally, I've noticed that boost's implementation of
> is_base_and_derived has the same access-checking problems as
> is_convertible. That could be easily fixed, as said in the thread
> about is convertible, by using function templates:
>
>
> typedef char (&no_type)[1];
> typedef char (&yes_type)[2];
>
> template
> struct identity { typedef T type; };
>
> template
> no_type is_convertible(...);
>
> template
> yes_type is_convertible(typename identity::type);
IMO your identity template only serves to trip up less capable compilers, it
does nothing to solve member access problems.
John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
On Tue, 28 Jan 2003 03:06:35 -0800, "Andrei Alexandrescu"
<[EMAIL PROTECTED]> wrote:
>"Thomas Witt" <[EMAIL PROTECTED]> wrote in message
>[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>> IIUC is_based_and_derived evaluates to true as well. Is a class T
>> strictly speaking a base class of itself?
>
>Yes
That's a convention of is_base_and_derived though. To the standard a
class is not a base of itself, so this convention should be
documented. In other words, you have to specify whether the ordering
is strict or not.
Incidentally, I've noticed that boost's implementation of
is_base_and_derived has the same access-checking problems as
is_convertible. That could be easily fixed, as said in the thread
about is convertible, by using function templates:
typedef char (&no_type)[1];
typedef char (&yes_type)[2];
template
struct identity { typedef T type; };
template
no_type is_convertible(...);
template
yes_type is_convertible(typename identity::type);
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_base_and_derived question
"Thomas Witt" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > IIUC is_based_and_derived evaluates to true as well. Is a class T > strictly speaking a base class of itself? Yes; any type is considered a supertype of itself. Andrei ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
