Re: float with 24-bit resolution

["Randy Brukardt" <randy@rrsoftware.com>]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:_x36b.22730$su.613585@news20.bellglobal.com...
> Randy Brukardt wrote:
> > You could "fix" that with a comment, but an explicit initializer works
> > just as well.
>
> But this also increases the maintenance cost if you change
> the nature or number of members of that object. It also
> creates a maintenance nightmare if the initialization
> defaults are changed (in the spec) but the explicit
> initialization undoes what is "correct" for it initially
> (ie. the worst case is when it compiles, but fails to
> work correctly because the incorrect initialization
> value remains, even though the spec has been corrected).

If your project has "visible" (i.e. non-private) record types where the
components can change, it has maintenance problems to begin with.
Initializers are the least of your problems. Inside the package,
initialization should always be done with aggregates (exactly so that missed
changes cause compile-time errors).

The problem here is the inconsistence of the language. Some types can be
implicitly initialized, and others cannot. That makes problems for private
types (because if you assume that they are implicitly initialized, you are
breaking privateness and/or significantly restricting the implementation (to
records and access types only). On the other hand, limited types can only be
initialized implicitly (that probably will change in Ada 200Y). Thus, it is
impossible for any rule to be completely consistent.

I do use implicit initializers in some cases (especially for limited types,
where nothing else is possible). But I prefer to make it explicit when
possible (generally reserving implicit initialization to marking an object
as "not valid").

                       Randy.