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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Top 10 Worst C# Features Date: Wed, 2 Sep 2015 14:39:39 -0500 Organization: JSA Research & Innovation Message-ID: References: NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1441222780 568 24.196.82.226 (2 Sep 2015 19:39:40 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 2 Sep 2015 19:39:40 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:27688 Date: 2015-09-02T14:39:39-05:00 List-Id: wrote in message news:alpine.DEB.2.20.1509021228510.5314@debian... ... >#2 Finaliz(ers) are fragile > >In Ada, the finalize procedure for an object can be called more than once, >Finalize should rather not raise an exception, ... apparently, C# >finalzisers suffer from similar problems: "any time a finalizer runs, you >could argue that the program either has a bug or is in a dangerous state, >such as being shut down unexpectedly via a thread abort". Based on the article, the situation in Ada is far less bad than the C# one. His description of C++ finalizers apply to Ada's as well: "[they] run deterministically, run on the current thread, and never run on partially constructed objects." Moreover, they always run when objects are destroyed, while apparently in C# they don't run for explicit calls to Dispose. Ada's issues come from two things: extremely rare cases involving exceptions where a finalizer might start twice, and the fact that someone can explicitly call it on an object. If one has control over the entire system, neither of these cases need happen; a program like AdaControl can enforce appropriate style rules to avoid problems. If not, it's relatively easy to make Finalize callable multiple times (you just need a "Valid" bit in the object, which is turned off by Finalize; if it's off, Finalize does nothing). Of course, Ada gets this by not supporting garbage collection on objects that have non-trival finalization (such an object cannot be garbage collected until the finalization has run, meaning they have to exist until they go out of scope, meaning no useful garbage collection can happen. Fixing that would probably introduce more problems (although if the points at which garbage collection could happen were appropriately limited it would not be a huge issue; if this issue is ever addressed in Ada, that would have to be the case). In any case, Ada's situation is nothing like the asynchronous mess he describes for C#. It may not be perfect, but it's a heck of a lot better than C#. Randy.