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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6b1a1ed8b075945 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!e34g2000pro.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Allocators and exceptions Date: Tue, 11 Sep 2007 12:07:06 -0700 Organization: http://groups.google.com Message-ID: <1189537626.913207.116840@e34g2000pro.googlegroups.com> References: <1189323618.588340.87180@o80g2000hse.googlegroups.com> <1189369871.672082.162750@50g2000hsm.googlegroups.com> <1189460936.295604.143720@r29g2000hsg.googlegroups.com> <1189502377.626510.172690@22g2000hsm.googlegroups.com> <5rjahxfvhazu.bol1ilmh6uew$.dlg@40tude.net> NNTP-Posting-Host: 85.0.246.232 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1189537628 23606 127.0.0.1 (11 Sep 2007 19:07:08 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 11 Sep 2007 19:07:08 +0000 (UTC) In-Reply-To: <5rjahxfvhazu.bol1ilmh6uew$.dlg@40tude.net> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: e34g2000pro.googlegroups.com; posting-host=85.0.246.232; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: g2news2.google.com comp.lang.ada:1892 Date: 2007-09-11T12:07:06-07:00 List-Id: On 11 Wrz, 14:27, "Dmitry A. Kazakov" wrote: > This error is likely unrecoverable, so you have to reconsider your design > which allowed such errors. I disagree. The error might be unrecoverable (like broken network cable), but might as well be worth retrying with modified parameters (like wrong credentials were provided by the user). Even in unrecoverable case I might want to gracefully reduce the functionality of the system. Sorry, there will be no music today, but please enjoy the party anyway - this sort of thing. If we assume that the exception is an unconditional indication of wrong design, then we might as well drop exceptions from the language altogether. > BTW, formally everything is exactly as you wished! Observe, that > > new T(-5) > > creates an object of the type T_Access. This object does not come to > existence and the compiler carefully eliminates any traces of this object. > Everything is fine! Except of the memory leak and the already created other components. > What you actually want, but didn't say it, is that T_Access would take care > of the things it points to, so its constructor (new) would. No. T_Access is not (yet) involved. This has to be handled entirely by the allocator, because the whole problem happens even before T_Access is assigned to my access variable. > > This is what allows me to keep abstractions and invariants: either I > > have the complete object with its guaranteed invariants, or there is > > nothing. Anything in between is mess. > > This is violated upon aggregation of initialized components with side > effects. I don't argue that this is good, I only state that this is the > current language design and that it would be quite challenging to alter. I understand that it cannot be changed. At least not shortly after the last standardization iteration. :-) But... did I mention that C++ handles this issue correctly? ;-) And no, it does not have any super-capable access types. A little bit smarter allocator is enough. -- Maciej Sobczak http://www.msobczak.com/