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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8a402d78988bdf2b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-12-21 05:35:55 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!dialin-145-254-037-037.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: [announcement] SYSAPI and SYSSVC for Windows Date: Sun, 21 Dec 2003 14:42:09 +0100 Organization: At home Message-ID: References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-037-037.arcor-ip.net (145.254.37.37) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.uni-berlin.de 1072013753 9905610 145.254.37.37 ([77047]) User-Agent: KNode/0.7.2 Xref: archiver1.google.com comp.lang.ada:3663 Date: 2003-12-21T14:42:09+01:00 List-Id: Ekkehard Morgenstern wrote: > "Dmitry A. Kazakov" wrote: >> The problem is to tell the customers, that *their* applications should be >> designed so that *our* DLLs and hardware drivers would not stray into an >> unpredictable state. > > What's the problem communicating this to the customer? We are not MS, to tell customers, that they are wrong. (:-)) >> > C++ is well-defined also, btw. There's already a number of ISO >> > standards for C and C++, >> >> A *number of* standards, fascinating! (:-)) > > For Ada, there's also an '83 and a '95 rationale. ;) Ada 95 practically includes Ada 83, with very minor exceptions. Rationale is not the standard, it is rather comments to the standard. BTW, there is also AARM - Annotated Ada Reference Manual. >> Come on! C++ does not have: >> >> 1. multiple dispatch; > > True, except for constructors and destructors. They're always called for > all derived classes of an object. This is not multiple dispatch. MD is when, for example: type Matrix is tagged ...; function "+" (X, Y : Matrix) return Matrix; -- This is dispatching in X, Y and the result In C++ only one (hidden) parameter can be dispatching. All others are contravariant, which leads to numerous nasty pitfalls >> 3. dispatch on access types; > > False. Method overloading based on parameters of different types, even > pointer types, is supported. Overloading, not overriding. In C++: class X {...}; void f(X * Ptr); // This is not a member of X! Formally f is not dispatching in Ptr. It is class-wide. Compare it with Ada; type X is tagged ... procedure F1 (Object : access X); -- This is a "member" procedure F2 (Object : access X'Class); -- This is not type Y is new X with ... procedure F1 (Object : access Y); -- This overrides F1 procedure F2 (Object : access Y'Class); -- This overloads F2 >> 4. differentiation between class-wide and specific types; > > Class-wide types in Ada roughly correspond to base classes in C++. No. A class-wide type is a closure of the derived types. C++ tries to equalize specific and class-wide types. The price is that C++ never become a fully OO langauge, while Ada can do it easily. It possible to make all types in Ada "tagged", even Boolean. >> 5. functions returning class-wide objects on the stack; > > True, but you can return a reference to an object. (I'm not sure if > passing a reference to a temporary object would work) This won't help, because of 4. The same type name is sometimes denotes class-wide, sometimes specific in C++. In declarations it is always specific, so you cannot do: declare X : Object'Class := Get_From_File; -- Any descendant of Object To achive same effect, you have to use the heap: X_Ptr * Object = Get_From_File (); // internally calls new ... free (X_Ptr); // do not forget to release it >> 7. formal derived type parameter for generics; > > False. Of course you can use derived classes or other types in templates. Georg Bauhaus has answered this >> Why? The following is OK: >> >> type T is limited private; >> private >> type T is limited record >> I : aliased Integer; > > Yes, but I is an Integer. Discrete types can always be aliased. > > In my case, it was an array of aliased types, and I wanted to create an > access to an array element. >> "Aliased" is the keyword for that. Objects of some types are always >> aliased: >> >> type T is tagged limited ...; > > so I could've just used a tagged limited record? > > Like this: > > type T is tagged limited > record > A : My_Array_Type; > end record; > > procedure F ( O : in out T ) is > Ptr : My_Array_Cell_Ptr; > begin > Ptr := O.A(1)'Access; > end; > > Right? No. It is unrelated. The thing you are getting access of has to be aliased. So it is the array elements which has to be, for example: type T is limited private; private type Integer_Array is array (Integer range <>) of aliased Integer; type T is limited record A : Integer_Array (1..3); end record; procedure F (O : in out T ) is begin ... O.A(1)'Access; -- This is OK, A(i) are aliased end; If the array elements be tagged, then you would need not write "aliased" in the array declaration. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de