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-Thread: 103376,ec21c3c7cdc7ff3e X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Mon, 20 Mar 2006 18:38:32 -0600 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <1142279908.327131.230200@j52g2000cwj.googlegroups.com> Subject: Re: Uninitialized variables (was: Re: private types) Date: Mon, 20 Mar 2006 18:38:40 -0600 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: <1rSdna-AGOKV1oLZRVn-uA@megapath.net> NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-1gBZ0oKiZtYQTWmrUkDAqgf7bwuYqrG9YAbXpkhCQTuDguTrUuI9KRl2ZurY7raO30+OyAhiAhu4NY9!RP4ud/xpFcSyqnPb4ql+j+9RHqIFXtgFvH5G48UhXD6ox1w3oC3baLnKbs9mmnCQi8G0Ze+TUAPt X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.lang.ada:3512 Date: 2006-03-20T18:38:40-06:00 List-Id: "Dirk Craeynest" wrote in message news:dvgh0s$rtu$1@apollo.cs.kuleuven.ac.be... > [This thread really is about uninitialized variables now, so I changed > the subject...] > > In article , > Randy Brukardt wrote: > >So I recommend initalizing everything (or assigning it immediately > >after the begin) that could be significant to performance. > > We did (and do) feel this is not a good approach, at least not when > using GNAT or another compiler that supports something like the pragma > Initialize_Scalars and enhanced validity checking. (followed by a number of quotes). I disagree in detail with your conclusions, but probably not in general. 1) Initialize_Scalars is an Annex H thing that is rarely available in Ada implementations. GNAT is the only one that I know of that has it. I don't think offering advice that most users can't follow is very helpful. 2) Initialized_Scalars does no good when you have full range types (which are very common in a compiler, for instance). In that case, it is equivalent to initializing to a random value, and worse, it gives a false sense of security. 3) "The initial value is meaningless". Here I agree and disagree with you. The agreement is that you shouldn't initialize to a meaningless value. The disagreement is that for most variables, there is an obvious initial value (like Null for access types) that is not meaningless. For instance, I have a lot of string processing code in the spam filter that have length variables. I usually initialize the length to zero (empty), because that *is* the initial state of the object. So, much of time there is a useful initialization. It think it is better to *avoid* uninitialized variables than to argue about how to *handle* uninitialized values. The example you gave: B : Natural := 0; if .... then B := 5; else B := 8; end if; is awful, I agree. But I'd probably write: B : Natural := 8; if .... then B := 5; -- else use the default values end if; instead, and the initial value is no longer meaningless. Similarly, I use a lot of blocks, and try to keep the declarations on variables to scopes where their initial values are known (or immediately initialized). Both of these are better than *any* technique to handle uninitialized variables. 4) As your note suggested, assuming that everything is tested is dangerous. It's necessary in the fielded system to protect against uninitialized variables causing weird results. I just prefer to do it from the beginning (by reducing them as much as possible). And I'd prefer to rely on compile-time warnings (which GNAT also does well, BTW) to get rid of them at the source. 5) Any extra cost from initializing objects to meaningful values early (and such cost is usually quite small) will quickly pay for itself. (I think that is in line with the conclusions of the paper, too). Conclusion: don't write uninitialized variables in the first place; but use your head to eliminate them - junk initializations are no better than the uninitialized variables that they replace. Mindless following of coding standards always produces junky code. Randy.