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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7a2d45f282a1da1c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-05 12:35:49 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!sn-xit-03!sn-xit-01!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: float with 24-bit resolution Date: Fri, 5 Sep 2003 14:37:12 -0500 Organization: Posted via Supernews, http://www.supernews.com Message-ID: References: <3F3CCB0F.543478AF@adrianhoe.nospam.com.my> <3f405ef4$1_1@news.tm.net.my> <3f54bf19_1@news.tm.net.my> <_x36b.22730$su.613585@news20.bellglobal.com> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:42190 Date: 2003-09-05T14:37:12-05:00 List-Id: "Warren W. Gay VE3WWG" 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.