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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.13.215.74 with SMTP id z71mr7284380ywd.16.1498309581241; Sat, 24 Jun 2017 06:06:21 -0700 (PDT) X-Received: by 10.157.66.43 with SMTP id q43mr262454ote.16.1498309581199; Sat, 24 Jun 2017 06:06:21 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!v31no395016qtb.0!news-out.google.com!s132ni465itb.0!nntp.google.com!f20no627832itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 24 Jun 2017 06:06:20 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=68.114.51.240; posting-account=HN9B-woAAACqJDcuOavWYdk7s1Vm8fv7 NNTP-Posting-Host: 68.114.51.240 References: <1ac5a44b-4423-443a-a7bb-2864d9abe78f@googlegroups.com> <1498048151.20885.28.camel@obry.net> <96174ea5-852d-44e9-8535-7c1eb24d5326@googlegroups.com> <8d3aff06-82df-485f-89e5-a50c326aab05@googlegroups.com> <66aa262e-2ac9-4016-b32d-e9fee14779e1@googlegroups.com> <88e2f18a-0786-4303-a5b8-fe82e8c81dcb@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <357b04d6-d00d-42e4-aebe-af1270f96efb@googlegroups.com> Subject: Re: Ada Annoyances From: pythoner6@gmail.com Injection-Date: Sat, 24 Jun 2017 13:06:21 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:47099 Date: 2017-06-24T06:06:20-07:00 List-Id: On Saturday, June 24, 2017 at 4:34:32 AM UTC-4, Maciej Sobczak wrote: > Because tagging (like v-table in C++) is a language design artefact that = enables dynamic binding, which has its costs and has nothing to do with aut= omated lifetime management. These concepts are orthogonal and there is no n= eed to entangle them together. Yes, I definitely agree with that - which is similar to the reason I starte= d this thread. > This has practical implications. In C++ the auto_ptr or scoped_ptr (or si= milar) wrapper has literally zero cost, both in space and in time. If the r= aw pointer has 4 bytes (on a 32-bit machine), the scoped_ptr wrapper will h= ave 4 bytes, too. Ada imposes unnecessary cost - again, both in space and t= ime. As I understand it, the penalty in Ada is going to some extra space for the= tag (how big is this? I haven't found much info on the size of a tag, whic= h I'm assuming is because this may be implementation dependent?), and the s= mart pointer will get passed around by reference, as opposed to by value wh= ich would make more sense. While for most part I'm not too concerned about = the extra space required for the tag (in other cases), for a smart pointer = that's probably about doubling the size which is unfortunate. Method calls won't be dynamically dispatched unless you're dealing with a S= mart_Pointer'Class and calling methods that take a Smart_Pointer (which I d= on't see much reason to do if you want a low overhead smart pointer), right= ? > > And how is C++ much different - other than that you can make destructor= s non-virtual >=20 > In a class that is not intented for use in a class hierarchy (like said R= AII wrappers) the destructor should *not* be virtual, as there is no reason= for it to be. >=20 > > (and therefore never dynamically dispatch, though I think the advice I = usually see is to make almost all destructors virtual to avoid the case whe= re the wrong destructor gets called). >=20 > This is not a complete advice. If the class is not part of any hierarchy,= there is only one destructor and always the right one will be called. Sure - I'm not saying it's necessarily the best practice, but I've certainl= y seen that advice given. Now that C++ has the final keyword, I think it's = probably safer to provide nonvirtual destructors as they can be marked fina= l to ensure that the destructor cannot be accidentally overridden. > > Again, I'm not quite sure I follow you here. What do you mean by "not c= ompatible with the lifetime of its parts"? >=20 > In C++ when the object of derived class is constructed, its base class co= nstructor is called first and at that time the object is considered to have= the Base dynamic type, which makes sense, as the derived parts have not ye= t been initialized (they will be initialized in the Derived constructor, wh= ich will happen later). Only after the base constructor finishes, the dynam= ic type of the object is "promoted" to Derived. This means that virtual cal= ls within the Base constructor will never dispatch to Derived variants, whi= ch is safer, as it prevents accidental access to not-yet-initialized parts = of the object from virtual functions. We say that from within constructors = (and destructors, where the same process goes in the reverse direction) the= static type is equal to the dynamic type of the object. > Ada does not have this feature and diaptching calls can access uninitiali= zed components from derived parts by means of dispatching to the not-yet-bo= rn parts of the object. >=20 > In this sense and this particular context, C++ offers better and stronger= (!) type safety than Ada. >=20 > --=20 > Maciej Sobczak * http://www.inspirel.com Ah, I see.