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=0.6 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, HK_RANDOM_FROM autolearn=no 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!news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc08.POSTED!20ae255c!not-for-mail Newsgroups: comp.lang.ada From: Justin Gombos Subject: Re: private types References: <1142279908.327131.230200@j52g2000cwj.googlegroups.com> User-Agent: slrn/0.9.8.1 (Linux) Message-ID: Date: Fri, 17 Mar 2006 04:33:15 GMT NNTP-Posting-Host: 129.44.77.228 X-Complaints-To: abuse@verizon.net X-Trace: trnddc08 1142569995 129.44.77.228 (Thu, 16 Mar 2006 23:33:15 EST) NNTP-Posting-Date: Thu, 16 Mar 2006 23:33:15 EST Xref: g2news1.google.com comp.lang.ada:3393 Date: 2006-03-17T04:33:15+00:00 List-Id: On 2006-03-14, Brian May wrote: > > He does have a point though - some languages will initialise all > variables to dummy values - this means you can get predictable > results in code that (wrongly) uses them before setting them to a > value. Beyond access types, I would not consider that feature you're describing helpful. In fact, it's more of a disservice. The first problem: initializing to zero, or some other "dummy" value of the compilers choice is likely to result in a valid value (sometimes), which only serves to /hide/ bugs in the cases where the object is used prior to a meaningful assignment. Then problem with user forced initialization (which is what the OP is after): it could mask the cases where reassignment is inevitable. IOW, suppose you have subprograms like this: function exists return boolean is --Later assignment to found_it is evitable -- found_it : boolean := false; begin if some_precondition then found_it := some_other_condition; end if; return found_it; end exists; In the above case, an initial value may persist if some path is not executed. The maintainer can immediately expect this to be the case upon seeing the initialization (assuming the author was competent). In other cases, an initial value may get overwritten no matter what. In these cases it makes more sense not to initialize, because it clarifies to the maintainer what kind of logic to expect before even looking at the body of code. It's always irritating to be reading someone elses code, and find that they've blanket initialized objects needlessly. It hides bugs, and also obscures the logic from the maintainer. We don't know enough about the OPs case to know whether forced initialization is wise, but he should be cautioned not to take this approach arbitrarily, or on a regular basis. It really depends on the situation. -- PM instructions: do a C4esar Ciph3r on my address; retain punctuation.