From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,T_SCC_BODY_TEXT_LINE, XPRIO autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Constancy of X'Address? Date: Sat, 8 Apr 2023 04:03:02 -0500 Organization: A noiseless patient Spider Message-ID: References: Injection-Date: Sat, 8 Apr 2023 09:03:04 -0000 (UTC) Injection-Info: dont-email.me; posting-host="8cffde185656e4854c99d85efea8bf85"; logging-data="1284362"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/eMNoROdhku48SorYNIWcddfpM21ILe0c=" Cancel-Lock: sha1:Pw3yXvAYpP9AuF+NisZ92e+8kvc= X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-Priority: 3 Xref: feeder.eternal-september.org comp.lang.ada:65079 List-Id: I agree with the other answers (for the most part). Not much is guarenteed about 'Address. But by-reference and aliased objects have to *work* like they are not moved. If the runtime can deal with moving such things, Ada doesn't care. As a practical matter, most Ada implementations assume objects don't move. Janus/Ada assigns everything at compile-time, so the only time anything moves is when it is created or destroyed. The big problem with garbage collection in Ada is that early finalization is not allowed (other than a few tiny exceptions in failure cases and [in post-Ada 22] certain function results.) So any object that might have a controlled part can never be garbage collected, even if there is no other use or access to it. Changing that is a very hard problem, as you cannot allow finalization to happen at any instant or by any arbitrary task (if you did, every finalization would be a race scenario, and every Finalize routine would need dedicated locking). I've suggesting allowing it for "unreachable objects" (not a useful definition by itself, it would need to be defined) at places where masters are being exited anyway (so finalization should be expected at those locations). But it's unclear if you can build a useful garbage collector that way (and what the overhead would be). Randy. "Niklas Holsti" wrote in message news:k94t2nFelgbU1@mid.individual.net... >A discussion in comp.arch (on the new C23 standard for C) brought up these >questions, which I could not answer with confidence: > > - Is the address of an object constant in Ada? That is, if I have some > object X in an Ada program, do repeated applications of X'Address always > return the same value? > > - Does the answer depend on how X is allocated (created): on the library > level, on the stack, or in a pool ("new")? > > The issue behind this question is whether an Ada program could use garbage > collection that moves objects around, for example a compacting collector.