June 02, 2005
"Derek Parnell" <derek@psych.ward> wrote in message news:lktv44kgbu1j.1tp9nxs3uqvmr.dlg@40tude.net...
> On Mon, 30 May 2005 22:50:29 -0700, Andrew Fedoniouk wrote:
>
>
> [snip]
>
>> class Url
>> {
>>    char[] _hostname;
>>    ...
>>    char[] hostname() { return _hostname.dup; } // Doh!
>> }
>>
>> if( url.hostname == "terrainformatica.com" )
>> // 32 bytes less in memory, just to compare it!
>>   ....
>>
>> Ideal from many points of view would be a solution with const
>>
>> class Url {
>>   char[] _hostname;
>>
>>   const char[] hostname() { return _hostname; } // Yep! this exactly what
>> we
>> need.
>>
>> }
>>
>
> Given the current semantics of D, could a workaround be that we give the caller the choice, thus making them take explicit responsibility for their usage.
>
> class Url
> {
>    private char[] _hostname;
>    ...
>    char[] hostname_unsafe() { return _hostname; }
>    char[] hostname()   { return _hostname.dup; }
> }

>
> char[] a;
> char[] b;
> a = url.hostname; // Gets a string with safety
> b = url.hostname_unsafe; // Gets a string without safety

Derek it is not a choice.
Nobody in good mental health will do such double implementation.
Easier to switch to C++.

const char[] hostname()   { return _hostname; }
const char[] hostname = url.hostname;
const char[] level1 = hostname[$-3..$];
char[] level2 = hostname[0...$-3]; // bang!

We do have const for int, double, etc.
Why not for arrays and pointers - they are also primitive types
builtin in language, right? Yes this is a bit different in implementation
but for the sake of consistency?

Jees, I am loosing big project for D and Harmonia....
Team is voting for C++. Only const! :(
Simply do not have moral rights to insist further.
That was really good chance to feed Harmonia....


>
> <offtopic>
> Of course, if we had return type function matching this would be a whole
> lot easier and legible.
>
> typedef char[] safe_string;
>
> class Url
> {
>    private char[] _hostname;
>    ...
>    char[] hostname()      { return _hostname; }
>    safe_string hostname() { return cast(safe_string)_hostname.dup; }
> }
>
> safe_string a;
> char[] b;
> a = url.hostname; // Gets a string with safety
> b = url.hostname; // Gets a string without safety
>
> But I should wake up from this dream now ... -)
> </offtopic>
>
> -- 
> Derek
> Melbourne, Australia
> 2/06/2005 10:12:16 AM


June 02, 2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Fedoniouk schrieb am Wed, 1 Jun 2005 17:55:04 -0700:
>> ....for having a facility in the
>> language to say "this thing shouldn't change value".
>
> exactly.
>
> It is enough to have  const T[]  and const T* as distinct types from just T[]  and T* .
>
> const T[] type has no opIndexAssign, length(int) and cannot be lvalue at
> all.
> Simple as 1-2-3. I really don't understand what is the motivation to do not
> have them.
>
> String literals are const char[] by definition.

Sadly it's not that simple. The content of the string literals are known at compile time and can thus be placed in an OS-protected memory area.

If the array content is mutable by default, the const attribute for arrays is a mere suggestion. Do a bit of pointer math or store arrays as elements in other arrays and the const attribute loses it's effect.

If the array content is by default immutable - that is, once an element
is set it can't be changed - the "mutable" attribute could be used to
allow the editing of array element. In difference to the current system
the compiler could only allow those cases where it can _prove_ that the
array is mutable. What happens if you store pointers/object
references in the array?!
In addition this has some negative impact for mixed closed-open
source projects as the compiler would have to treat all arrays comming
from the closed source part as immutable.

The third way is to allow only assigning and not changeing any var. It's neat but pointer math gets in the way again.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCnsBx3w+/yD4P9tIRAj+BAKCZTrUBYd4ARfWuxMcmN9126dyVmQCcDI5/
St2gvmZjNrzBbITklIQYb+g=
=WdJv
-----END PGP SIGNATURE-----
June 02, 2005
Thomas Kuehne wrote:
> If the array content is by default immutable - that is, once an element
> is set it can't be changed - the "mutable" attribute could be used to
> allow the editing of array element. 

Now there's a different idea. Talk about CoW enforcement :-)

> In difference to the current system
> the compiler could only allow those cases where it can _prove_ that the
> array is mutable. What happens if you store pointers/object
> references in the array?!

Doesn't have to prove anything if the mutable aspect is part of the type; right, Thomas? Aliases upon the array still have to go through the same type-matching procedure; Yes?

If you cast an immutable type to a mutable type, then all bets are off; just as they are with *cast(void *)0 = 0;

> In addition this has some negative impact for mixed closed-open
> source projects as the compiler would have to treat all arrays comming
> from the closed source part as immutable.

Is it still an issue if third-party code can be declared/proto-typed appropriately?
June 02, 2005
"Thomas Kuehne" <thomas-dloop@kuehne.this-is.spam.cn> wrote in message news:hsr2n2-ic3.ln1@lnews.kuehne.cn...
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andrew Fedoniouk schrieb am Wed, 1 Jun 2005 17:55:04 -0700:
>>> ....for having a facility in the
>>> language to say "this thing shouldn't change value".
>>
>> exactly.
>>
>> It is enough to have  const T[]  and const T* as distinct types from just T[]  and T* .
>>
>> const T[] type has no opIndexAssign, length(int) and cannot be lvalue at
>> all.
>> Simple as 1-2-3. I really don't understand what is the motivation to do
>> not
>> have them.
>>
>> String literals are const char[] by definition.
>
> Sadly it's not that simple. The content of the string literals are known
> at
> compile time and can thus be placed in an OS-protected memory area.
>
> If the array content is mutable by default, the const attribute for arrays is a mere suggestion. Do a bit of pointer math or store arrays as elements in other arrays and the const attribute loses it's effect.
>
> If the array content is by default immutable - that is, once an element
> is set it can't be changed - the "mutable" attribute could be used to
> allow the editing of array element. In difference to the current system
> the compiler could only allow those cases where it can _prove_ that the
> array is mutable. What happens if you store pointers/object
> references in the array?!
> In addition this has some negative impact for mixed closed-open
> source projects as the compiler would have to treat all arrays comming
> from the closed source part as immutable.
>
> The third way is to allow only assigning and not changeing any var. It's neat but pointer math gets in the way again.
>
> Thomas

Thomas, I am not proposing here any flags changeable in runtime or existing
there.
I was thinking aloud before about them but not in this message.
I did tests already with flags - indeed they do not work in some cases.
Let's forget about them and focus on just a const type modifier

const T[] and T[] has exactly the same binary layout in runtime.

The only difference is on compiler level (as in C++).
Lets imagine that we have

const char[] t = some_other_array;

uint find( const char[] where, const char[] what)
{
.....
}

uint replace( char[] where, const char[] from, const char[] to)
{
.....
}

find(t, "hello"); // fine
replace( t, "c++", "d" ); // bang! compile time error : cannot change const
value.

const type modifier is not to much complicated
currently it is supported for scalars. We need to extend it
to arrays and pointers with slightly modified meaning.
Close to what C++ has. But not exactly.
I thing we don't need to go to const methods or so they are
too shaky even in C++.

Just a type modifer for POD types (as currently) and for
arrays and pointers which are generally speaking for D are also POD
types.

This is it. Not a rocket science.

Andrew.










June 02, 2005
"kris" <fu@bar.org> wrote in message news:d7mbac$c2d$1@digitaldaemon.com...
> Thomas Kuehne wrote:
>> If the array content is by default immutable - that is, once an element is set it can't be changed - the "mutable" attribute could be used to allow the editing of array element.
>
> Now there's a different idea. Talk about CoW enforcement :-)
>
>> In difference to the current system
>> the compiler could only allow those cases where it can _prove_ that the
>> array is mutable. What happens if you store pointers/object
>> references in the array?!
>
> Doesn't have to prove anything if the mutable aspect is part of the type; right, Thomas? Aliases upon the array still have to go through the same type-matching procedure; Yes?

Thanks, Kris. This is exactly what I have in my mind.

>
> If you cast an immutable type to a mutable type, then all bets are off; just as they are with *cast(void *)0 = 0;
>
>> In addition this has some negative impact for mixed closed-open source projects as the compiler would have to treat all arrays comming from the closed source part as immutable.
>
> Is it still an issue if third-party code can be declared/proto-typed appropriately?

This "all arrays comming from the closed source part as immutable." sounds
like Ride of the Valkyries from Wagner.
I can feel two layers of sense there but only managed to get one :).
Thomas, for the D sake, what it was all about?

Andrew.






June 02, 2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

kris schrieb am Thu, 02 Jun 2005 00:15:46 -0700:
> Thomas Kuehne wrote:
>> If the array content is by default immutable - that is, once an element is set it can't be changed - the "mutable" attribute could be used to allow the editing of array elements.
>
> Now there's a different idea. Talk about CoW enforcement :-)
>
>> In difference to the current system
>> the compiler could only allow those cases where it can _prove_ that the
>> array is mutable. What happens if you store pointers/object
>> references in the array?!
>
> Doesn't have to prove anything if the mutable aspect is part of the type; right, Thomas?

This isn't sufficent.

class C{
	<immutable> int i;
}

void bugger(){
	C c = new C;
	c.i = 2; // **ok**
	<mutable> int* i = &c.i;
	*i = 1; // ***bug**
}

> Aliases upon the array still have to go through the same type-matching procedure; Yes?

In the sense that "<mutable> t" and "<immutable> t" are two distinct types.

> If you cast an immutable type to a mutable type, then all bets are off; just as they are with *cast(void *)0 = 0;

How about enforcing that immutable types can only be casted to immutable types?

<immutable> type[] a;
<immutable> void* b = cast(<immutable> void*) a; // legal, the target is immutable
<mutable> void* c = cast(<mutable> void*) a; // illegal, the target is mutable.

This isn't sufficent. Let's rewrite the sample.

class C{
	<immutable> int i;
}

void bugger2(){
	C c = new C;
	c.i = 2; // **ok**
	<immutable> size_t ptrI = cast(<immutabe> size_t)(cast(<immutable> void*)) &c.i);
	<mutable> size_t ptrM = ptrI;
	<mutable> void* v = cast(<mutable> void*) ptrM;
	<mutable> int* i = cast(<mutable> int*) v;
	*i = 1; // **bug, but legal if mutability is a plain attribute**
}

>> In addition this has some negative impact for mixed closed-open source projects as the compiler would have to treat all arrays comming from the closed source part as immutable.
>
> Is it still an issue if third-party code can be declared/proto-typed appropriately?

This would reduce the the protection to a suggestion.

As can be seen: a simple <mutable> attribute isn't a sufficent protection.

The compiler would have to do a quite extensive flow analysis to provide even very limited mutable access.

If the "default <immutable>" is limited to arrays, how deep would the array be protected? What about pointers as array elements?

class D{
	<mutable> int i;
}

<immutable> D[] o;
o.length=1;
o[0]= new D; // **ok**

o[0]= new D; // **bug**

o[0].i = 1; // legal or illegal?

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCnt1K3w+/yD4P9tIRAuebAKCAgW0XGeL7/5QkZ+GmZnwefI+hzQCfdv6B
isJeMx63fCvqJgoxpQhzKAk=
=Q3ak
-----END PGP SIGNATURE-----
June 02, 2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Fedoniouk schrieb am Thu, 2 Jun 2005 00:38:54 -0700: <snip>
> Thomas, I am not proposing here any flags changeable in runtime or existing
> there.
> I was thinking aloud before about them but not in this message.
> I did tests already with flags - indeed they do not work in some cases.

The only way I am aware of to enforce const at runtime could be compared to Java's String pool...

> Let's forget about them and focus on just a const type modifier
>
> const T[] and T[] has exactly the same binary layout in runtime.
>
> The only difference is on compiler level (as in C++).
> Lets imagine that we have
>
> const char[] t = some_other_array;
>
> uint find( const char[] where, const char[] what)
> {
> .....
> }
>
> uint replace( char[] where, const char[] from, const char[] to)
> {
> .....
> }
>
> find(t, "hello"); // fine
> replace( t, "c++", "d" ); // bang! compile time error : cannot change const
> value.
>
> const type modifier is not to much complicated
> currently it is supported for scalars. We need to extend it
> to arrays and pointers with slightly modified meaning.
> Close to what C++ has. But not exactly.

Now that is the tricky part. ;)
What would be the const rules for arrays and pointers/references?
How/When would those rules be checked and/or enfored?

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCnuIR3w+/yD4P9tIRApaoAKCfmszRUHdzY+D1ZqBE28fWkQ1cBQCcDouw
Jjmq2a1Wkah6dhYchFArC+g=
=VHXo
-----END PGP SIGNATURE-----
June 02, 2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Fedoniouk schrieb am Thu, 2 Jun 2005 00:51:30 -0700:
>>> In addition this has some negative impact for mixed closed-open source projects as the compiler would have to treat all arrays comming from the closed source part as immutable.
>>
>> Is it still an issue if third-party code can be declared/proto-typed appropriately?
>
> This "all arrays comming from the closed source part as immutable." sounds
> like Ride of the Valkyries from Wagner.
> I can feel two layers of sense there but only managed to get one :).
> Thomas, for the D sake, what it was all about?

If mutability is a "suggestion" than there is no problem with open source projects that use close source libs. However if mutability is to be strictly enforced, we would either need runtime checks or would have to treat the arrays from the closed source part as immutable.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCnuJO3w+/yD4P9tIRApxdAJ9f/18fE6/lblc/VPVItHbhkR9JXQCdGW/E
IUXVTD7HHXPJy0qhpHxFfLE=
=b0Hv
-----END PGP SIGNATURE-----
June 02, 2005
Walter wrote:
> "Eugene Pelekhay" <pelekhay@gmail.com> wrote in message
> news:d7hfuh$1ejl$1@digitaldaemon.com...
> 
>>May be I'm dummy, but I don't see in this example why this other
>>languages must copy it 10 times. For my implementation of reference
>>counted string in my C++ project, copy will be performed also 0 times.
>>And if there is more then 1 reference to instance exsits it's only one
>>copy operation will be performed. I see only one advantage in current
>>implementation of string - not need to check or increment/decrement
>>reference counter, but instead of this string duplication is required
> 
> 
> You're right that you can avoid excessive copying by doing ref counting.
> 
> Reference counting carries with it other penalties - storage must be
> allocated for the ref count, every copy increments the count, and every
> reference that goes out of scope must decrement the count. Add in exception
> handling, and the price is high (although C++'s mechanisms hide that price
> from you).
I know about price I pay for ref counting. But in my field as in many others it is a reasonable price to be sure that my application will not freeze for some time to perform garbage collection. Another thing which is significant for me it is destructor calls from garbage collector. I don't care when memory will be released, but i won't be sure that destructor is called as soon as all references to object are gone. If last is not guaranteed then my code will look like in Java, with enormous amount of *try finally* blocks with forced call to cleanup methods. IMHO to be successful D language must reduce development cycle and this is only reason big bosses will understand.

> 
> Ref counting would make it impractical to do D's array slices.
Yes this is nice feature, but some one (like me) can say that bitfields in C is also very nice feature I use quite often (in binary exchange protocol between my devices). This is all about constness and CoW and without it I only see hardly findable errors in code (if code is not just simple one page test.d). Don't think I'm against this nice feature.
> 
> Furthermore, in the presence of garbage collection, layering on top a
> reference counting mechanism probably means you'll want to ditch the gc and
> go with a full ref counting architecture for every object. In my experience,
> such is slower than using mark/sweep gc.
>  
Just remember all fields where performance is important i can list some of them:
1) real time systems programming (gc is not acceptable if it is not deterministic)
2) game with extensive usage of latest hardware (freezing for for some time in unpredictable moments. Who will play such game?)
3) embedded systems (resources in most cases are limited, so You need to utilize all resources You have)
4) scientific calculations

As You see high performance requirements often go hand in hand with deterministic execution time, which is not guaranteed in the case of GC or at least existing implementation.

PS: For whom who see this post and thinks he wont to rip D language, I'm not. I'm praying last ~5 years for success of D and I'm here to bring all my experience to make it successful. I'm not starting flame war here 'cause I really like the language
June 02, 2005
"Thomas Kuehne" <thomas-dloop@kuehne.this-is.spam.cn> wrote in message news:eb43n2-na4.ln1@lnews.kuehne.cn...
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Andrew Fedoniouk schrieb am Thu, 2 Jun 2005 00:51:30 -0700:
>>>> In addition this has some negative impact for mixed closed-open source projects as the compiler would have to treat all arrays comming from the closed source part as immutable.
>>>
>>> Is it still an issue if third-party code can be declared/proto-typed appropriately?
>>
>> This "all arrays comming from the closed source part as immutable."
>> sounds
>> like Ride of the Valkyries from Wagner.
>> I can feel two layers of sense there but only managed to get one :).
>> Thomas, for the D sake, what it was all about?
>
> If mutability is a "suggestion" than there is no problem with open source projects that use close source libs. However if mutability is to be strictly enforced, we would either need runtime checks or would have to treat the arrays from the closed source part as immutable.
>
> Thomas
>

I think I see now what you mean ...
Thanks, Thomas.