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-Thread: 103376,703c4f68db81387d X-Google-Thread: 109fba,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid109fba,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!newsread.com!news-xfer.newsread.com!newspeer.monmouth.com!newsfeed.icl.net!newsfeed.fjserv.net!feed.news.tiscali.de!newsfeed.freenet.de!151.189.20.20.MISMATCH!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada) Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <1lr611thktbau$.1dj95z21h7l5v.dlg@40tude.net> <97kpu5gkgo1r$.kc4nx7cxjziw$.dlg@40tude.net> <1110543138.32171@athnrd02> Date: Fri, 11 Mar 2005 14:34:57 +0100 Message-ID: NNTP-Posting-Date: 11 Mar 2005 14:31:37 MET NNTP-Posting-Host: aa90609c.newsread2.arcor-online.net X-Trace: DXC=Li5M9I2lcDQ5U85hF6f;DjW\KbG]kaMHliQbn6H@_EIK\]BX8l1jfGWRXZ37ga[7Jn919Q4_`VjIB8=X\UUgbkD X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:9131 comp.lang.c++:45127 comp.realtime:1274 comp.software-eng:4840 Date: 2005-03-11T14:31:37+01:00 List-Id: On Fri, 11 Mar 2005 14:12:14 +0200, Ioannis Vranos wrote: > Dmitry A. Kazakov wrote: > >> Heap is far slower than stack. Also stack is much safer, because objects >> allocated on the stack have visible scopes, as compared to adventures with >> pointers. Do you want to add one more indirection layer - smart pointers, >> or do it even worse by using GC? > > Regarding Storage_Error exception, C++'s one is bad_alloc, which is > guaranteed to *never fail* in case of memory starvation. Even if exception object is 100GB large? > About stack. Strictly speaking, C++ standard does not define any stack > apart from a stack container , but "automatic storage" and "dynamic > storage". > > It is common though the first to be called "stack" and the second "heap" > or "free store". > > It is an implementation's/platform's job to provide stack and heap. > > Usually the stack is limited in comparison to the heap, and it sounds > strange to me that in Ada there is a large stack. My guess is that you > are using the heap for data storage implicitly(?) and you think you are > using the stack. Stack here means LIFO. It is not necessarily the machine stack, though in most cases it will be. I think there is no need to explain why LIFO allocation / deallocation strategy is in order of magnitude more efficient than heap? Neither should I explain why local to task (thread) memory is better than the global heap in any concurrent program and especially in ones running on multi-processor machines... > Are you familiar with "Resource Acquisition is Initialisation" (RAII) > technique? This is supported by C++ and used by all standard library > containers. = smart pointers. Yes. It is a widely used technique to regain the safety lost while switching from stack to heap. It adds additional performance / space penalty to what heap already has. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de