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.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,5bcc293dc5642650 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.68.27.132 with SMTP id t4mr16946244pbg.3.1319668893556; Wed, 26 Oct 2011 15:41:33 -0700 (PDT) MIME-Version: 1.0 Path: p6ni1017pbn.0!nntp.google.com!news2.google.com!news3.google.com!feeder.news-service.com!weretis.net!feeder1.news.weretis.net!feeder.erje.net!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Why no Ada.Wide_Directories? Date: Wed, 26 Oct 2011 17:41:30 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <9937871.172.1318575525468.JavaMail.geo-discussion-forums@prib32> <418b8140-fafb-442f-b91c-e22cc47f8adb@y22g2000pri.googlegroups.com> <7156122c-b63f-487e-ad1b-0edcc6694a7a@u10g2000prl.googlegroups.com> <409c81ab-bd54-493b-beb4-a0cca99ec306@p27g2000prp.googlegroups.com> <1rlz5gwqmeizn$.fwqpl0mhzf54$.dlg@40tude.net> <1w7i4ekc7yvjx$.60o908ry5lhc$.dlg@40tude.net> <5279agttaub8.1pl7pt496l1am$.dlg@40tude.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1319668892 8593 69.95.181.76 (26 Oct 2011 22:41:32 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 26 Oct 2011 22:41:32 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-RFC2646: Format=Flowed; Original Xref: news2.google.com comp.lang.ada:14195 Date: 2011-10-26T17:41:30-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:ci96gr5yzmpp$.1mwky141c6e78$.dlg@40tude.net... > On Tue, 25 Oct 2011 14:22:27 -0500, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" wrote in message >> news:5279agttaub8.1pl7pt496l1am$.dlg@40tude.net... >>> On Fri, 21 Oct 2011 14:53:11 +0200, Yannick Duch�ne (Hibou57) wrote: >>> >>>> Le Thu, 20 Oct 2011 19:35:21 +0200, Dmitry A. Kazakov >>>> a �crit: >>> >>>>>> What's missing from Interface type introduced with Ada 2005 ? >>>>> >>>>> 1. Most Ada types do not have interfaces >>>> Eiffel has this, and this is 1) not perfect (may lead to performance >>>> issue) 2) rarely used in practice >>> >>> There is no performance loss. >> >> Anytime you have a construct that allows multiple inheritance, there is a >> large performance loss (whether or not you use the multiple inheritance). >> You can move the performance loss from one construct to another (i.e. >> dispatching calls, access types, etc.) but you can't get rid of it. > > There is no time/memory loss, at all. For the types in question any legal > Ada 2005 program would generate exactly same code as it would be the > change. First of all, I was including Ada 2005 interfaces in this complaint -- so "Ada 2005" is irrelevant (you've already gone over the edge at that point). You *might* be right about Ada 95 programs, but it would require a substantial increase in compiler complexity in order to support that. But Ada compilers are already very complex - fairly close to the point where the complexity would overwhelm the ability to get them correct. It's much more likely that a much simpler design would be used for a pervasively multiple inheriting language where everything is much more expensive. You might think that such a compiler's output could be optimized to a more efficient version. Indeed, that was the original premise behind Janus/Ada (optimization could eliminate the cost of generic sharing, pervasive heap allocation of objects, etc.) But it didn't work, the optimizations were too complex to be very practical other than in the simplest of circumstances. Ultimately, we bit the bullet and supported multiple representations for arrays, records, and the like, because that got rid of a lot of the expense at the source. But it also added a whole lot of complexity to the compiler. It's possible that a from-scratch compiler design could do better, but I doubt it. And it seems unlikely that anyone will be doing one of those for Ada anytime soon. Randy.