December 20, 2005
>Ok i see now. Make a special value that tells us if the variable has been assigned to. But what about something like
>
>struct Point{float x, y, z;}
>
>Point? getOrNotAPoint()
>{
>   is(something)return null;
>   else return Point(1,2,3);
>}
>
>How would compiler implement that?
No easy way.
I do not think that these '?' problem could be ever solved generally for every
types. I can't see general solution for structs since they can be used without
references (which can be null).

>The solution with ranges works great for numeric types, but what about other types?
Yes. It works only for integral types.
BUT.
For an object does this problem really exists? No.
They can be 'null'.

>What if i want int[]? where is that bit of information stored.
Boxing into Object should work. Not to nice for arrays :-(
I am not sure but I remember as dynamic arrays work a bit similar as objects,
so maybe they can be 'null' as well. If it is true the problem is not a problem.

Tamás Nagy


December 20, 2005
MicroWizard wrote:
>>Ok i see now. Make a special value that tells us if the variable has been assigned to. But what about something like
>>
>>struct Point{float x, y, z;}
>>
>>Point? getOrNotAPoint()
>>{
>>  is(something)return null;
>>  else return Point(1,2,3);
>>}
>>
>>How would compiler implement that?
> 
> No easy way.
> I do not think that these '?' problem could be ever solved generally for every
> types. I can't see general solution for structs since they can be used without
> references (which can be null).
> 

Yes easy way :)
The problem could be solved generally if another byte or 4bytes were added to the normal type. I see someType? being to someType something simillar as someType[] is to someType* adding a bit of information (length in dynamic arrays and assigned flag in ? types)

> 
>>The solution with ranges works great for numeric types, but what about other types?
> 
> Yes. It works only for integral types.
> BUT.
> For an object does this problem really exists? No.
> They can be 'null'.

No doesn't really exist for objects.

> 
> 
>>What if i want int[]? where is that bit of information stored.
> 
> Boxing into Object should work. Not to nice for arrays :-(

Not nice at all.

> I am not sure but I remember as dynamic arrays work a bit similar as objects,
> so maybe they can be 'null' as well. If it is true the problem is not a problem.
> 

IMO dynamic arrays are objects (and IMO static arrays should also be to make them runtime allocatable, but that is another discussion), but i remember there was a discussion about that some time ago and i can't remember what the conclusion was but i think that in D an empty array and null array are the same unless you reduce the length of an alocated array to 0, and then it isn't 0 anymore.

I may be wrong about what i said but it was something as equaly confusing.

IMO there should be a way to tell apart 0 length and null arrays.
December 20, 2005
Ivan Senji wrote:
> IMO dynamic arrays are objects (and IMO static arrays should also be to make them runtime allocatable, but that is another discussion), but i remember there was a discussion about that some time ago and i can't remember what the conclusion was but i think that in D an empty array and null array are the same unless you reduce the length of an alocated array to 0, and then it isn't 0 anymore.
> 
> I may be wrong about what i said but it was something as equaly confusing.
> 
> IMO there should be a way to tell apart 0 length and null arrays.

Replying to myself: I did a little test and it seems that arrays work as expected. Array is null if it's length is 0, but for example although length of "" is 0 that char[] isn't null. Makes sense.
December 20, 2005
MicroWizard wrote:

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

Yeah.

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

I guess C# developers from M$ just forgot what sign after 'int' was used in the language that they once was told about (first year of college and it was C, after they left college as they boss earlier did) and so they used '?' thinking they gonna change it when they will find out which one character it was. But I remember which char was it! I hope the behavior you would like is accessible using '*' sign.

What you want is:

int* i;
// here i is uninitialized

i = new int;
// here i is initialized


// you can use *i like this:
*i = 2 + *i;
// (I guess you can even use alias or mixin to forget about '*')

i = null;
// here i is again uninitialized

Hmmm. We could even send a letter to M$ to help those people in they quest.
December 20, 2005
> Why are these 'val' stuff? What is the problem with inheritance? A detailed example would be nice.

Agree that it is not obvious.

Reason is simple: when you are dealing with variables allowing undetermined
state
at some point you need determined values:

So instead of

length_v margin;
....
int m;
if( margin.undefined )
     m = 10;

you can write:

m = length_v(margin, 10);


Andrew.


December 20, 2005
Errata:

Instead of
> m = length_v(margin, 10);
>
read:
m = length_v::val(margin, 10);


December 20, 2005
On Tue, 20 Dec 2005 16:02:16 +0100, Ivan Senji <ivan.senji_REMOVE_@_THIS__gmail.com> wrote:
> Ivan Senji wrote:
>> IMO dynamic arrays are objects (and IMO static arrays should also be to make them runtime allocatable, but that is another discussion), but i remember there was a discussion about that some time ago and i can't remember what the conclusion was but i think that in D an empty array and null array are the same unless you reduce the length of an alocated array to 0, and then it isn't 0 anymore.
>>  I may be wrong about what i said but it was something as equaly confusing.
>>  IMO there should be a way to tell apart 0 length and null arrays.
>
> Replying to myself: I did a little test and it seems that arrays work as expected. Array is null if it's length is 0, but for example although length of "" is 0 that char[] isn't null. Makes sense.

I think you're looking at it backwards :)

A null array has a null data pointer, an empty array has a non-null data pointer. Both have a length of 0. So, the difference is the data pointer, not the length, the length is the same in both cases.

To get an empty char array you can assign "" to it, i.e.

char[] a = "";

or in the general case slice a 0 length section from another array i.e.

int[] a;
a ~= 1;

int[] b = a[0..0];

The problem is that if you then set the length to 0, the data pointer is free'd or set to null. This means the empty array becomes a null array, which makes the distinction inconsistent and therefore less useful (and I believe it _is_ very useful).

The solution is to keep the distinction when setting the length to 0. Changes in length should never set the data pointer to null. Off the top of my head the only operation that should set the data pointer to null is:

b = null;

Regan
December 21, 2005
Now it is much clearer. Thank you.

Tamás

In article <do9m8t$210g$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>Errata:
>
>Instead of
>> m = length_v(margin, 10);
>>
>read:
>m = length_v::val(margin, 10);




1 2 3
Next ›   Last »