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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,cd962bca2451dfbc X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: static objects in ADA Date: 1999/04/25 Message-ID: <7fv781$60e$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 470667292 References: <7foacg$3t1@news1.newsguy.com> <4IaN6CA84vI3EwTh@tioman.demon.co.uk> X-Http-Proxy: 1.0 x17.dejanews.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Sun Apr 25 14:01:37 1999 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-04-25T00:00:00+00:00 List-Id: In article <4IaN6CA84vI3EwTh@tioman.demon.co.uk>, Mark Elson wrote: > I slipped up here in my terminology - whilst I was > thinking of static initialisation being at compile/link > time the relevant C++ keyword is > actually const. What prompted me to think of this > approach is the common > use of const character arrays to store config control > info as strings in > object files. As far as I know, there is no requirement in C++ that const objects be initialized at link time. Such a requirement is pretty hard to state, since at the level of a semantic definition, such a distinction has no semantically observable effects. In practice, C++ compilers very reasonably do what you expect ... In the case of Ada, pragma Preealborate is intended to have much the same effect, but here to, it is impossible to guarantee that you get link time initialization, since this is hard to talk about, and the best we can do in Ada is the following "requirement": 3 The implementation shall not execute any memory write operations after load time for the elaboration of constant objects declared immediately within the declarative region of a preelaborated library package, so long as the subtype and initial expression (or default initial expressions if initialized by default) of the object_declaration satisfy the following restrictions. The meaning of load time is implementation defined. The "implementation defined" at the end is of course a worry, but it is unavoidable, any attempt to formally define load time would fail. In practice, if you write type x is array (0 .. 100_000_000) of boolean; vx : x := (others => False); I would guess many implementations would output object code that would expand this as part of loading on a system where to do otherwise would generate a gigantic 100 meg or bigger load module. In GNAT we have provided the additional restrictions identifier: pragma Restrictions (No_Elaboration_Code); which really means what it says, and if you use this, you can be sure that you have NO code at all for runtime elaboration. Here is the restrictions pragma in action: 1. pragma Restrictions (No_Elaboration_Code); 2. package q is 3. type x is array (0 .. 100_000_000) of boolean; 4. vx : x := (others => False); | >>> violation of restriction "no_elaboration_code" at line 1 5. end q; If you change the range of the array to something more reasonable, the message will go away, since the compiler will be willing to initialize small arrays at link time. Again, the best advice is contact your vendor, the trouble with general posts on CLA is that they tend to go in the wrong direction sometimes :-) Everyone assumed you were talking about the static scope issue, when in fact your concern about load time initialization for safety critical programs was a completely different one. Robert Dewar Ada Core Technologies -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own