Re: static objects in ADA

[Mark Elson <mark@tioman.demon.co.uk>]

First of all thanks to all who replied to this thread, they have all
been very useful especially Sam's


>Mark Elson asked:
>> Is there an equivalent declaration (in ADA 95) to the static used in
>> C++, i.e. so that objects are created at link time rather than at run
>> time?
>
>Depends on what you mean.
>
>Vocabulary: I'll use "C-static" to refer to the "static" variables of
>C and C++.  "Static" is used differently in the Ada manual.
>
>As others have told you, Ada variables declared in a library package
>spec or body (not contained in a procedure or function declaration)
>are C-static.
>

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.

>> I am being told that using objects will
>> greatly increase my app start time because of object creation overhead.
>> Any comments appreciated.
>
>Hmm.  I wonder if this advice is oriented toward C++.
>
>Vocabulary: I'll reserve "object" for object-oriented entities, that
>is, an instance of a class in C++ or a value of a tagged type in Ada.
>I'll assume that's what you're talking about here.  I'll use "item"
>to mean a regular variable.  The Ada Reference Manual refers to
>anything that uses memory (variables, constants, tasks, protected
>objects) as an "object."
>
>Perhaps your advice refers to dynamic memory allocation.  I believe
>that some object-oriented features in C++ depend on an "object" being
>referred to by a pointer, but I didn't think they had to be allocated
>at run-time.  That is, I thought you could take the address of an
>"automatic" variable and use that.

You're quite right - virtual functions can be called through pointers or
references to automatic variables (so long as they still exist, of
course).

The "advice" has really annoyed me. It came from Green Hills and they
were actually telling us that we should abandon an object-orientated
design and use structured methods instead to avoid the overhead of
object initialisation (which they believed would give us "long" start-up
times). In fact, we are not creating any significantly large objects at
start-up time, anyway, so I felt this was very bad advice. IMO, at the
implementation level OO and structured methods might only differ in the
organisation of code. There should be no reason why OO-designed code
should be inherently less efficient than a structured design. Possibly
inefficient activities such as dynamic memory allocation can be avoided,
by design, if required. In fact we intend to do this for other reasons
as the app will be safety-critical.

Thanks again for the replies.
-- 
Mark Elson