From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,342dcd67e9ca73ee X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!proxad.net!213.200.89.82.MISMATCH!tiscali!newsfeed1.ip.tiscali.net!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: tagged record child: override constructor? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1126591134.797303.318920@z14g2000cwz.googlegroups.com> <1uri5gd2n7om0.1ujkzb26ayxdx.dlg@40tude.net> <1126625009.709876.226260@f14g2000cwb.googlegroups.com> <225337460.SlYKbeB8eD@linux1.krischik.com> <87vf14him5.fsf@ludovic-brenta.org> <1idpvzxcxfckw.mrs8nw3eu4ks$.dlg@40tude.net> <13wyu4lwsmzmz.ktc3t2av54yv$.dlg@40tude.net> <1126705974.984997.227590@z14g2000cwz.googlegroups.com> <1126718176.448703.193860@g44g2000cwa.googlegroups.com> <1aroipmwspnb8.zqxtxhb4t06u$.dlg@40tude.net> <1126731371.081850.90860@g44g2000cwa.googlegroups.com> <12v93t1k4i81i$.sm5jmg8q3lpk$.dlg@40tude.net> <1126790380.573573.78220@g44g2000cwa.googlegroups.com> <1w82ustqd4vak$.mv9c3tcxa6sx.dlg@40tude.net> <1126810455.448696.262570@g44g2000cwa.googlegroups.com> Date: Fri, 16 Sep 2005 11:32:07 +0200 Message-ID: NNTP-Posting-Date: 16 Sep 2005 11:32:07 MEST NNTP-Posting-Host: 8a5f2dd3.newsread2.arcor-online.net X-Trace: DXC=U^>QE=n?D9BSA]l6DQ8mU0GR8mWRXZ37ga[7jn919Q4_`VjiB8=X\UUgbkd X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:4783 Date: 2005-09-16T11:32:07+02:00 List-Id: On 15 Sep 2005 11:54:15 -0700, Hyman Rosen wrote: > Dmitry A. Kazakov wrote: >> There is no actual type, there is only the type specified by the contract. > > There is an actual type, and it can be recovered from the object > through redispatching (or even by simply extracting the type tag, > if I'm not mistaken). You are. Tag is said to be "associated", the standard does not require to engrave it on the objects. Moreover, X'Tag is valid for class-wide objects only! See 3.9 (11) >> is "by-reference" a type property? > > Yes. In C++ you have "type" and "reference to type" and the two > are completely different. So T and T& are two different types, then why methods of T can be used with T&? Is there a type conversion between them? When T is converted to T&, why it dispatches to methods of T rather than to ones of T&? A poor C++ newbie asks why the following does not compile: class T& {}; // Isn't T& a type? > A "reference to type" may have as its > referant a sub-object of the given type which is a base class of > a larger object. An object of "type" is exactly that. Both of > these concepts are useful. T != T& is useful, you say. Then why T /= T'Class is not? (:-)) >> Why by-copy objects (of which type?) have one (which?) type while >> by-reference objects (of which type?) have more than one? > > It's not the "by-copy" that gives something a type. When you declare > that a parameter has a class type, it has that type and nothing more. But the actual parameter may have another type. It leaks! > It's a separate object within its lifetime, and when the function is > called, it's initialized with a copy of the argument. A copy, really? It is a strange copy, when the actual parameter is of a derived type. Your theory leaks. > When you have > a parameter of reference type, when the function is called it's > initialized to refer to the appropriate subobject of the argument. Now you have a difficult job to explain what is a subobject. Which type it has. Is it a by-reference or by-copy type, etc. Poor old C++ newbie! > (Actually, newbies in C++ face the same confusion between paramaters > of T and T& as Ada newbies do between T and T'Class.) Huh, that's the minor confusion they face in C++... >> It is rubbish. In a typed language an object has a type, only one type. > > You may not like it, but that's the way it's done, including in Ada. No, Ada is consistent here: "A type is characterized by a set of values, and a set of primitive operations which implement the fundamental aspects of its semantics. An object of a given type is a run-time entity that contains (has) a value of the type." - ARM 3.2 (1) >> No. Trap is when the declared type does not determine what's going on. > > In C++ the declared type does determine what's going on. Finally! (:-)) I.e. C++ is not a typed language. What else evidence you need? > In Ada, you are permitted to go from the declared type to the > classwide type, so by your argument C++ reflects the contract > model better than Ada does. Allowing specific to class-wide conversion was in my view a mistake. However, even though it contradicts to Ada's model, technically it is not a big issue, because tagged types are by-reference anyway. When Ada will have T'Class for non-tagged types as well, for those this conversion will not be allowed. >> I (again) formulate the properties of Ada's model: > > But no Ada compiler implements the model the way you would like > it to be. There is a great difference between not yet implemented things and ones which cannot be under any circumstances. Alone to separate T and T'Class was a revolutionary breakthrough, importance of which many people still do not grasp. >> Now show me how C++ or Java could accomplish 1..12. > > C++ doesn't have polymorphic variables or copying, so some things > are out of reach. But the main problem with your approach is that > no one wants to implement differently sized pointers for T'Class > than for T. Egh? Ada vendors have used fat pointers for decades. Even in C++, print sizeof() of a member function pointer! > For all your posting on this, I've yet to see an > implementor so taken by your approach that he's willing to adopt it. Come on, c.l.a. is a chat root. Do you think I have influence of Bjarne Stroustrup, or what? (:-)) >> What should that code prove? That pointers to members is a total mess in >> C++? Everybody knows it. > > It proves that they're equal. *That's* what everyone knows. Pointers are equal, so what? >> They cannot be same because they act on different types. You cannot call >> B::g() on A. The same question again, is C++ typed? > > As I said, in OO languages like Ada, C++, and Java, when you have a > reference type, the object to which it refers may be a typed base > subobject of a larger object of different type. See? It is of a different type. Now observe that B <: A, it is an asymmetric relation. So B::g() cannot be same as A::g(), because that would require equivalence B :=: A, which is wrong. This is why you cannot call B::g() on A, even if B::g() was inherited, not overridden. My example shows this. At least here C++ is consistent. [my "theory" on] The difference between A::g() and B::g() inherited from A is that B::g() is a composition of three functions: B::g() :=: (B *) o A::g() o (A *) The argument "this" is first converted from B* to A*, then this->A::g() is called, then it is converted back to B*. These conversions might be identity ones (not always in presence of multiple inheritance, BTW), but that gives no right to declare A::g() and B::g() same. [my "theory" off] -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de