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