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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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-27 17:49:03 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!news.gtei.net!chcgil2-snh1.gtei.net!news.bbnplanet.com!wn14feed!worldnet.att.net!bgtnsc04-news.ops.worldnet.att.net.POSTED!not-for-mail From: Dave Thompson Newsgroups: comp.lang.ada Subject: Re: [announcement] SYSAPI and SYSSVC for Windows Message-ID: References: X-Newsreader: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 28 Dec 2003 01:49:03 GMT NNTP-Posting-Host: 12.75.203.79 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc04-news.ops.worldnet.att.net 1072576143 12.75.203.79 (Sun, 28 Dec 2003 01:49:03 GMT) NNTP-Posting-Date: Sun, 28 Dec 2003 01:49:03 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:3868 Date: 2003-12-28T01:49:03+00:00 List-Id: On Sun, 21 Dec 2003 14:42:09 +0100, "Dmitry A. Kazakov" wrote: > Ekkehard Morgenstern wrote: > >> A *number of* standards, fascinating! (:-)) > > Aside from the "development under actual use" period, C has had two full standards (89/90 and 99) and one Normative Amendment (95), compared to two for Ada. Not *that* different. > > 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. > There was a rationale in C89 (the ANSI-only standard), and is a draft still being worked on last I looked for C99, but neither of them as complete or IMO clear, much less integrated, as the ARM annotations. > >> 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 > Or more generally types not in the same hierarchy like the "standard" procedure Eat (X: Animal; Y: Food); > In C++ only one (hidden) parameter can be dispatching. All others are > contravariant, which leads to numerous nasty pitfalls > No, in C++ child method parameters are the same type. In fact, trying to make an overrider covariant instead hides the parent method, which seems to be a fairly common bug. The *return* type (which in C++ does not contribute to dispatching) can be covariant, but only as a pointer or reference; as you note there are no polymorphic/classwide *values* in C++. The only *contra*variance is in pointer-to-member conversions, to which Ada has no direct analog I know of. > >> 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: > For an actual object it is always specific; for a pointer or reference always polymorphic/classwide iff the class has any 'virtual' methods (i.e. has a vtable = is tagged and not just a record/struct/data). > declare > X : Object'Class := Get_From_File; -- Any descendant of Object > > To achive same effect, you have to use the heap: > Or other programmer-managed storage like static, a private pool, etc. But not automatic, which is the point. > X_Ptr * Object = Get_From_File (); // internally calls new > ... > free (X_Ptr); // do not forget to release it > You presumably meant free(Object). In fact, officially you must use delete iff it was allocated with new* and free() iff it was allocated with C-style malloc-or-friends; implementations of these are not required to be interchangeable, though they usually if not always are. (* and even worse delete [] if the new was actually of an array, even though that may be hidden inside the other module. Which is a good reason to provide and use an e.g. do_delete method instead.) - David.Thompson1 at worldnet.att.net