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,80e74153f40106ab X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-11 01:20:06 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: Weird controlled behavior - Gnat 3.15p NT Date: Thu, 11 Sep 2003 10:23:09 +0200 Message-ID: References: <5d6fdb61.0309040725.3403aa29@posting.google.com> <3F57B071.5030206@attbi.com> <592rlv0pak1cghri31iueh0mm144hv8kpm@4ax.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: news.uni-berlin.de 1063268135 22835134 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:42373 Date: 2003-09-11T10:23:09+02:00 List-Id: On Thu, 11 Sep 2003 03:46:56 GMT, Hyman Rosen wrote: >Dmitry A. Kazakov wrote: >> You might say that the above is rubbish. Not at all. It is a design >> pattern for self-destructing objects. > >Not at all. It's a well-known and good pattern, as you say. > >> Now imagine what should happen if somebody would allocate >> Foo on the stack? > >Undefined behavior. You are not allowed to do that, and if you do, >the behavior of the program is unspecifed by the language. (The >workaround is to make the destructor protected, by the way. Then the >compiler will prevent such objects from being allocated on the stack, >because the destructor will be inaccessible.) > >If you call a destructor yourself, you must make sure that the >compiler will not call the destructor again on that object (which in >fact no longer exists, except as a region of storage with undefined >contents). As you see the problem exists. The source is an ability to call a destructor explicitly and also an ability to call them from the methods. For many reasons, it is widely used, but it is a very dangerous and bad thing. >From design point of view, constructor and destructor should be invisible from the methods. They are not methods and are not a part of the interface. That we have to do such things both in Ada and C++ is a deficiency. However, I cannot say how to avoid it in all cases. In case of self-destructing objects, there is a safe alternative solution: smart pointers + object reference counts. Unfortunately both Ada and C++ do not allow an effective, "coder-friendly", transparent implementation of smart pointers. For example, Ada has half-transparent access types, but no user-defined ones, etc. And do not tell me stories about templates! (:-)) Only a full-blown ADT may help to solve the problem! --- Regards, Dmitry Kazakov www.dmitry-kazakov.de