Re: float with 24-bit resolution

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message news:vlhpbhsvhh5564@corp.supernews.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).

Well, I suppose when I use tagged types, the internals are usually
private, so I generally don't run into this. However, I would suggest
IMHO, that even the public components are much better initialized
(at least by default) based upon the designer's original intent
(ie. in the spec.)  OTOH, if the members are public, then it
is open to some question about how the members should be used 8-)

In my mind it comes down to the simple engineering practice that
you centralize things that are subject to change. This is why
things like an error code are generally defined in one place.
Sure I could define that same constant everywhere else, and
make it the same initially, but it is a maintenance nightmare
later when that value changes. Even worse if it can change, but
still compile and go unnoticed until something fatal happens.
The same principle holds for record member initialization.

So I maintain that unless you have a good reason to override
the default initialization, it is better left alone.

> 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.

Explicit initialization is similar in principle to a non-normalized
database. You have duplication of information, when the initialized
values are the same. Normalized database designs are preferred (though
not always achieved in practice).

Conversely, normalization of data means that your data is centralized.
This centralizes your "maintenance" and ensures that if you change that
value that you have got it correct everywhere else that it is needed.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg