Movement against float.init being nan

apz28 home at home.com
Sun Aug 21 19:57:52 UTC 2022


On Sunday, 21 August 2022 at 17:56:58 UTC, drug007 wrote:
> On 8/21/22 20:28, claptrap wrote:
>> On Sunday, 21 August 2022 at 16:51:51 UTC, Walter Bright wrote:
>>> Consider the following pattern, which doesn't appear
>>>
>>>
>>> 1. x is default initialized to NaN. bar(x) produces a NaN 
>>> result on everything dependent on x. User knows there's a 
>>> problem.
>>>
>>> 2. x is default initialized to 0. bar(0) may exhibit 
>>> problems, but these problems won't necessarily be noticed.
>> 
>> This is the problem, you suggest that if a variable is zero 
>> initialised in error the problems it causes "wont necessarily" 
>> be noticed.
>> 
>> I'm saying that's not true, I'm saying it will almost always 
>> be noticed.
>> 
>> 
>> 
>
> It will be noticed but what price? You've initialized all vars 
> to 0 so how do you know that this exactly initialization to 
> zero is wrong? To detect it you should track down manually 
> checking the intermediate results that is manually calculate 
> results and compare to what you get. It takes much more time 
> than checking if the value is NaN.

Price for this float=NaN & char=FF
1. Runtime bloat -> all struct/class with (float or char) need 
special initializer
2. Slow -> all struct/class not able to utilize zero initialized 
from memory manager
3. Inconsistent with other value types (all zero bits)
4. Aggregated/Sum float var should start with zero

So -> Better error when var is not initialized than this special 
value



More information about the Digitalmars-d mailing list