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 <class B, class D> struct is_base_and_derived { static const bool value = __built_in_is_base_and_derived<B, D>::value; }; Simple and easy. No need to rely on strange overloading and conversion ranking rules that, then, could be changed in response to some DR to close some other loophole. Probably I would opt for that even if the standard provided a normal C++ implementation (except verifying that my compiler is able to compile it, especially if it is an implementation like Rani's one :-) ). >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. Yeah yeah... > 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. If! Now, to finish exposing my point of view: we are all, I think, C++ fans, right? Well, we are all *amused* by code like Rani's. We all like it, and we are all astonished that something new can be discovered in C++ every day, and proud of understanding how it works. Ok, now we have it and it is into boost, ready to prove "on the field" that it works. So let's use it. When it comes to create new libraries or new language features for the standard, then we should all try hard to put our passion on one side and think: what we have at hand? Does it "seem" to work, or does it work? Isn't it that we want to standardize it just for a sort of "pride" to make that clever thing available to the world? Why do we want to put it in the standard if we have it already in a public available library? Also, as to standardizing, the argument you gave "having it as an operator requires a language change, and that's likely several years away" is moot, because it years away even as library stuff. Genny. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost