Re: private types

["Frank J. Lhota" <NOSPAM.lhota@adarose.com>]

Maciej Sobczak wrote:
> Justin Gombos wrote:
> 
>> ....
>>
>> Beyond access types, I would not consider that feature you're
>> describing helpful.  In fact, it's more of a disservice.  
> 
> So you have the whole pragma as such "disservice":
> 
> http://www.adaic.org/standards/95aarm/html/AA-H-1.html

Actually, the purpose of the Normalize_Scalars pragma is to eliminate 
any dependency on default initializations. The idea is to fill those 
scalars that are not initialized by the user with some extreme value, 
preferably out of range, so that any use of an uninitialized value can 
be readily detected.

The Normalize_Scalars pragma is the high level version of the "DEAD 
BEEF" option provided by many Unix C compilers / linkers. As you may 
recall, the C standard specifies that any static data not initialized by 
the user is implicitly initialized to 0. With the "DEAD BEEF" option, 
the static data not initialized in the code is filled with the hex bytes 
0xDEADBEEF, which results in outrageous integer / floating point / 
string values. Again, the point of this option is to eliminate 
dependence on implicit initialization.

>> 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.
> 
> Right. Then, why not minimize the scope of the object to the extent when 
> it's never even visible before being initialized with the value that is 
> meaningful in the given context? It's not always possible, of course, 
> but in many (most?) cases programmers tend to put all variables at the 
> beginning of some rather coarse-grained scope (for example, beginning of 
> the procedure or function), and later wonder what is the "right" initial 
> value for them. It's the misplacement of declaration that is a primary 
> source of problems and this is what should be actually addressed.
> 
>> 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;
> 
> Single entry - single exit syndrome? :)
> 
> 


-- 
"All things extant in this world,
Gods of Heaven, gods of Earth,
Let everything be as it should be;
Thus shall it be!"
- Magical chant from "Magical Shopping Arcade Abenobashi"

"Drizzle, Drazzle, Drozzle, Drome,
Time for the this one to come home!"
- Mr. Lizard from "Tootor Turtle"