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,52fd60a337c05842 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-14 07:46:21 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: ada paper critic Date: Fri, 14 Jun 2002 16:51:14 +0200 Message-ID: <8avjgu8bnkifee01ffu5i4h247n3khl7ub@4ax.com> References: <3D095F70.8090001@telepath.com> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: fu-berlin.de 1024065980 6412909 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:25940 Date: 2002-06-14T16:51:14+02:00 List-Id: On Fri, 14 Jun 2002 14:19:14 +0200, Immanuel Scholz wrote: >Dmitry A. Kazakov wrote: > >> On Fri, 14 Jun 2002 14:35:27 +1000, Dale Stanbrough >> wrote: >> >>>Just thinking about it, don't Ada's "non constructor" construcor >>>functions require you to build items on the heap, then copy them >>>into the variable, rather than bulding them inplace? >> >> I believe, in worst case, they will be copied from the stack. > >Is there any difference (left alone cache missis) in copying from heap or >copying from stack? Surely. Heap allocation/deallocation is very expensive as compared with stack ones. Things getting even worse in a multiprocessor system where heap is shared, so a spin lock must be taken. Then heap management might have an unbouded time [=inacceptable for real-time systems]. >> There are IMO more serious problems with OO in Ada, but most of them >> can be addressed to other languages as well. Others, like non-OO task >> and protected object types, can be excused by the fact that other >> languages have no such types at all. > >no "protected" state is IMHO an advantage. I think protected members are >evil doing more harm than good, but this is antoher story.;-) Actually I meant Ada's protected objects and not the visibility rules. There is a great need to have protected objects extensible (tagged). At the same time it is not very clear (at least to me), how to do it. As for protected members in C++ sense, I believe that Ada's "private" is closer to C++ "protected", than to "private", when child packages or derived types are considered. --- Regards, Dmitry Kazakov www.dmitry-kazakov.de