Re: Ada Annoyances

[Robert A Duff <bobduff@TheWorld.com>]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> (Apologies for a delayed reply.)

No need to apologize.  I certainly only pay attention to
comp.lang.ada occasionally.

> You are right, but this feature would be used only or mainly in embedded
> programs, which usually already contain unportable, low-level stuff:
> task stack sizes, record representation clauses, etc.

I would use it even in nonembedded systems.

I don't buy the idea that just because some of one's embedded code
needs to be nonportable/low-level, it's OK to force other stuff
to be, when it's not logically necessary.

If you're not interfacing with external hardware or similar,
the compiler should compute record layouts/sizes.

>> And not maintainable -- if you
>> delete a big type, or make it smaller, you're now wasting space.
>
> If the feature would be adopted, I imagine a friendly compiler would (at
> least optionally) tell me that I am wasting space, or that the given
> Maximum_Size is too small, and what would be the minimum valid value (as
> GNAT does now for 'Size clauses that give a too-small size) even if it
> requires some bind-time or link-time global check. That is a
> quality-of-implementation issue.

If it can warn about too-large max size, then it can compute the
max size for you.  Yes, it has to be a global analysis.

Too-small max size is easy -- that can be done at compile
time for each type.

> Well, the "binder" part of the compilation system does some global
> stuff. And I would not be surprised if link-time "relocation"-type
> computations could be (mis-)used to compute the maximum size of any type
> in a class.

Well, if you implemented this feature in GNAT, you'd be proven right.
I don't think AdaCore is going to spend time on it any time soon.

> Some compilers already support stack-size analysis, which is a similar
> global analysis.

Yes.  ARG has always shied away from requiring such things.

> I would like to allow that (default initialized components of type
> Root'Class), but I would not much mind having to initialize such
> components explicitly.

OK.

>> If so, what is the 'Tag of the various components?
>> "Undefined" is not a very satisfying answer.
>
> I agree that "undefined" would not be good. The natural answer seems to
> be that the default initial tag is that of the Root type, but then we
> must assume that it is not an abstract type.

But root types are usually abstract.

>> These things are analogous to records with defaulted discriminants.
>
> Yes, that has been my mental model (and it is the implementation used in
> the main SW component that I would like to switch over to class-wide
> types).
>
>> The language makes some (unsuccessful!) attempt to prevent
>> uninitialized discriminants.
>
> Interesting -- I did not know that the attempt is not fully
> successful. Is it easy to explain when the attemp fails?

Quite easy:

    Uninit : Integer;
    X : Some_Record (Discrim => Uninit);

In a simple case like that, compilers likely warn.
But it's not hard to hide the uninitialized variable
from the compiler.  E.g. a component of a heap-allocated
record -- compilers can't warn about that, because it
would cause too many false positives.

- Bob