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 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
