[boost] Re: is_base_and_derived question

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2003-01-31 13:02:46

On Fri, 31 Jan 2003 16:15:49 +0100, Terje Slettebø
<tslettebo_at_[hidden]> wrote:

>>From: "Gennaro Prota" <gennaro_prota_at_[hidden]>
>> 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.
>
>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 should be built-in language support for this. I've just
>pointed out some consequences of either approach.

Yes, I know. It's just that I have heard so many times the argument
about breaking existing code that it bothers me a bit, especially
because there are "famous precedents" in the C++ history where this
has been done for much less important reasons. Take e.g. a look at the
message with ID

   threadm=bgbdsu4sa9hd1bdanpf5ru7neqnh5l932a%404ax.com

from google's archive. It's about and, bitand, and the other
alternative spellings; here's a quote:

<quote>

Francis Glassborow:

>Actually I rather like the alternatives, I have never known anyone using 
>them confuse logical and bit-wise operators while I have seen such 
>confusion in almost all code using the traditional symbols.

Me:

FWIW, I have never seen them confused. However you should admit that
the alternative spellings are quite contrary to the spirit of C++ (if
nothing else, I think one who doesn't program with enough attention to
distinguish logical from bitwise operations CANNOT ever program in C
or C++, even with the alternate spellings) and that they are a whole
bunch of reserved words, whereas almost every day on this group we see
objections to the introduction of a new keyword for much more
judicious reasons than preventing confusion between symbols.

</quote>

The only answer that I got to that objection is that the code breaking
was old (alternative spellings are, in fact, an old addition), as if
an old breakage was a good one :-/ Now, isn't that a little
irritating? As you see, it was nothing against you.

I've also snipped the rest of the post because it was really too long;
also, honestly, it was a little biased, with questions like:

 - Do you know any better, perhaps more proved way, to do it now?
   If not, then what are you arguing about?

 - By having it in the standard library, it will be available to the
   world, yes. Isn't that a good thing?

Did you ask the first question thinking to the new semantics (any
base, accessible or not)? Otherwise the answer is trivial. And then, I
don't think you find me so intelligent to answer yes to the first one
or so stupid to answer no to the second. I just said that if we make
it available to the world, then it must have proven on the field that
it works. Also, you said:

>The library TR will be done before a possible next
>revision of the standard, and although the TR is not normative, it is likely
>that it will also be included in the next version of the standard, and that
>library vendors will likely bring their libraries up to conformance with the
>TR, when it comes.

Do you think that a programmer may be so zealous to know the latest
additions to his standard library, and still not know boost? And, even
if so, how do interpret the standard? As a sort of "advertising" to
make things known to people? To me standard has a **strong**
connotation of "high quality", so before putting something into it I
want to be sure.

P.S.: if you reply to this, please snip the off-topic parts (there are
many).

Genny.