[boost] Re: is_base_and_derived question

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2003-01-30 13:21:09

On Thu, 30 Jan 2003 15:13:19 +0100, Terje Slettebø
<tslettebo_at_[hidden]> 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.