Recenty I have to work with C# in VS2005 (poor me ;-)

The new CLR has expanded possibilities for value types which I've found interesting. Maybe it can be introduced to D as well.

"int?" is a type like "int" but "null" is allowed signing, the variable is not initialized or is out of range.

In C and C++ I have often faced the problem, I needed to spare a value of an integral type to sign the value is out of range. Reserving zero or -1 is always a pain. I had to take care of assignments comparison, etc.

To box it into an Object like .NET does seems to me a nightmare, much better it can be handled like ranges (as it was mentioned here before).

To solve the problem the compiler could allocate a value for "uninitialized" for every '?' types reducing the acceptable range by one value for these types. Also the compiler could manage the assignments and comparisons, not to cross range boundaries.

For me it looks easy to implement. But I am curious also. Please let me know your thoughts!

Tamás Nagy

MicroWizard wrote:

> To solve the problem the compiler could allocate a value for "uninitialized" for
> every '?' types reducing the acceptable range by one value for these types. Also
> the compiler could manage the assignments and comparisons, not to cross range
> boundaries.

D uses "nan" for the floats, ...
"\xFFFF" for code units and ...
(drum roll) ... "0" for ints. :-)

> In C and C++ I have often faced the problem, I needed to spare a value of an
> integral type to sign the value is out of range. Reserving zero or -1 is always
> a pain. I had to take care of assignments comparison, etc.

I think you will need to continue to reserve those values in D too.
Not perfect, perhaps, and not really consistent either. But anyway...

--anders

MicroWizard wrote:
> Recenty I have to work with C# in VS2005 (poor me ;-)
> 
> The new CLR has expanded possibilities for value types which I've found
> interesting. Maybe it can be introduced to D as well.
> 
> "int?" is a type like "int" but "null" is allowed signing, the variable is not
> initialized or is out of range.
> 
> In C and C++ I have often faced the problem, I needed to spare a value of an
> integral type to sign the value is out of range. Reserving zero or -1 is always
> a pain. I had to take care of assignments comparison, etc.
> 
> To box it into an Object like .NET does seems to me a nightmare, much better it
> can be handled like ranges (as it was mentioned here before).
> 
> To solve the problem the compiler could allocate a value for "uninitialized" for
> every '?' types reducing the acceptable range by one value for these types. Also
> the compiler could manage the assignments and comparisons, not to cross range
> boundaries.
> 
> For me it looks easy to implement. But I am curious also.
> Please let me know your thoughts!
> 

I think the something? types are an interesting concept but i doubt it will get into D soon. As for being hard to implement, i don't think it would be that hard. And it would certainly be usefull.

>D uses "nan" for the floats, ...
>"\xFFFF" for code units and ...
>(drum roll) ... "0" for ints. :-)

nan is fine for any kind of floats.

>> In C and C++ I have often faced the problem, I needed to spare a value of an integral type to sign the value is out of range. Reserving zero or -1 is always a pain. I had to take care of assignments comparison, etc.
>
>I think you will need to continue to reserve those values in D too. Not perfect, perhaps, and not really consistent either. But anyway...

Yep. The problem is not that I can not solve the problem.
I onlye feel there should be a nicer way.

Like we use unions and structs in D without bitfields and we have bit arrays
with their clumsy behaviours. They work now but we still want they to work
better ;-)
(((Or at least my not so humble being :-)))

So I think it would be nice to have something clear solution like 'nan' for integral types too.

Tamás Nagy

MicroWizard wrote:

>>D uses "nan" for the floats, ...
>>"\xFFFF" for code units and ...
>>(drum roll) ... "0" for ints. :-)
> 
> nan is fine for any kind of floats.

I suppose, but I still think it would have been much more consistent
to make all the values start out as zero. Including float/char, too ?

> So I think it would be nice to have something clear solution like 'nan' for
> integral types too.

Just to make *all* types have useless .init's, one could use "-1" ?
But we would still need three-valued* boolean, sorry "bit", values...

--anders

* true, false, unknown

Anders F Björklund wrote:
> MicroWizard wrote:
> 
>>> D uses "nan" for the floats, ...
>>> "\xFFFF" for code units and ...
>>> (drum roll) ... "0" for ints. :-)
>>
>> nan is fine for any kind of floats.
> 
> I suppose, but I still think it would have been much more consistent
> to make all the values start out as zero. Including float/char, too ?

I'm normally a huge proponent for consistency, but in this case I prefer the D initialization method.  I only wish there were hardware supported trap values for integers as well.

> Just to make *all* types have useless .init's, one could use "-1" ?
> But we would still need three-valued* boolean, sorry "bit", values...

-1 is still a valid integer value.  At least 0 is what we typically want to default initialize ints to so the current default isn't quite as likely to introduce hard to find bugs.  As for bit and such, were there an integral trap value then bit should be initialized to that, but false/0 fits in its absence.


Sean

Sean Kelly wrote:

>> I suppose, but I still think it would have been much more consistent
>> to make all the values start out as zero. Including float/char, too ?
> 
> I'm normally a huge proponent for consistency, but in this case I prefer the D initialization method.  I only wish there were hardware supported trap values for integers as well.

I prefer zero and "might not have been initialized" warnings, myself...

It's just that with the floating point types, then it's an "error" to
use the uninitialized values (and punishable by getting NaN results),
but when it comes to integers then it's suddenly OK to rely on that
the default initializer is zero and use it without assigning to it ?

If this is a handy feature, then couldn't floats start at zero as well ?

--anders

Some of us lost the point :-(

There are definitive difference between "uninitialized" and
"invalid value".
The first case can be handled by compiler policies.
The second one can't.

The question is, should we make difference between them or not?

If we want spare memory, we must accept bits as they are. If we want to use hardware traps for floats, do the same. For integers we have the choice what to do, and how to do.

Tamas Nagy

.
>I prefer zero and "might not have been initialized" warnings, myself...
..
>If this is a handy feature, then couldn't floats start at zero as well ?
..

MicroWizard wrote:

> Some of us lost the point :-(

Several, it seems... (including me)

Sorry for hijacking your thread to whine about .init values

> There are definitive difference between "uninitialized" and
> "invalid value".
> The first case can be handled by compiler policies.
> The second one can't.
> 
> The question is, should we make difference between them or not?
> 
> If we want spare memory, we must accept bits as they are.
> If we want to use hardware traps for floats, do the same.
> For integers we have the choice what to do, and how to do.

I don't understand what you are trying to say here...

And I don't know *how* you could make such a "nullable"
integer - without making it into an object like .NET/Java ?

--anders

MicroWizard wrote:
> Some of us lost the point :-(
> 
> There are definitive difference between "uninitialized" and
> "invalid value".
> The first case can be handled by compiler policies.
> The second one can't.

I think Walter would argue that compiler policies for this sort of thing are inexact, and thus should be avoided.  Though others might argue that some checking is better than none at all.  This seems to be a simple difference in philosophies, and Walter's wins out in this case :-)

> The question is, should we make difference between them or not?

I'll admit that I'm kind of on the fence with this issue.  It's very easy to become reliant on the integer default, and that does occasionally make me wish for zero default initialization for all primitives.  But I still like the motivation behind NaN initialization and would even be willing to live with a change in the integer default if such a trap value comes available.  So overall, I think it's slightly more useful to have trap initialization whenever possible, as it really does make the occasional initialization error easier to track down.


Sean