On Sat, 05 Mar 2005 11:31:03 +1300, Regan Heath wrote:

> On Fri, 04 Mar 2005 19:52:38 +0100, Jan-Eric Duden <jeduden@whisset.com> wrote:
>> Anders F Björklund wrote:
>>> Jan-Eric Duden wrote:
>>>
>>>>> Strings in D are protected from overwriting by the Honor System™...
>>>>
>>>>
>>>> How can a D coder know if it is safe to store just the reference or if
>>>> he needs to make a copy.
>>>> Right now, to be on the safe side - he actually needs to make a copy.
>>>> Otherwise, somewhere in her system or in external libraries the string
>>>> might get changed without her knowledge.
>>>   Copy-on-Write and immutable strings have a great advantage over
>>> deep copying and mutable strings, both when it comes to performance
>>> and when it comes to thread-safety (avoiding locks is also performance)
>>>  Along with slices and garbage collection, it gives D great speed...
>>>  What is needed is a method in the language to make sure that this
>>> is enforced, when passing arrays to other modules and functions ?
>>> Without it, as you say, strings *could* be modified by the method.
>>>  But I'm still hoping that it can be done without const / class...
>>>  --anders
>>>  PS. See also the "immutable strings" thread, and others like it.
>> If i can get immutable string without a class and const, I'd be happy.:)
>>
>> I wonder how this can be implemented without one of these concepts?
> 
> I think the first step is enforcing 'constness' on 'in' parameters.
> 
> That will basically say, for this function:
>    void foo(char[] a, inout char[] b);
> 
> a will not be modified, b might be modified.
> 
> It's a contract. It needs to be enforced.

It is enforced - 'a' itself is not modified. However, whatever 'a' refers to may be modified.

import std.stdio;
void foo(char[] a, inout char[] b) { a = "abc"; b = "def"; }
void main()
{
  char[] X = "123";
  char[] Y = "456";
  writefln("before X=%s, Y=%s", X, Y);
  foo(X, Y);
  writefln(" after X=%s, Y=%s", X, Y);
}

So what we need to be able to express, is a way to tell the compiler that the data referred to is not to be modified, and not just the referrer.

-- 
Derek Parnell
Melbourne, Australia
5/03/2005 10:09:41 AM

"Walter" <newshound@digitalmars.com> wrote in message news:d07ohk$f7d$1@digitaldaemon.com...
>
> "Mike Parker" <aldacron71@yahoo.com> wrote in message news:d07dbj$24e$1@digitaldaemon.com...
>> For the C++ types, I think an STL equivalent is the big thing. To this end, I really believe either DTL or MinTL needs to be integrated into core Phobos as part of a 1.0 release. This will make people in both camps happy (Java developers love their Collections).
>
> I understand that, but a DTL is probably going to be a D 2.0 feature. But
> part of the problem is a perception issue. D handles already, in the core
> language, much of the functionality of STL. (For an example, see
> www.digitalmars.com/d/cppstrings.html) People briefly look at D, and
> wonder
> where the 'string class' is. It takes a bit more in depth look at D to
> realize that a string class for D would be redundant, as would be vector
> classes, slice classes, for_each kludges, hash collections, etc. One other
> large reason for the existence of STL is memory management. D does
> automatic
> memory management.
>
> DTL needs go at least one or two conceptual steps beyond STL, because D already handles much of the core point of STL.

Do dynamic arrays in D do automatic resizing like std::vector in C++?  If not, a vector template would be useful.

-Craig

On Sat, 5 Mar 2005 10:14:52 +1100, Derek Parnell <derek@psych.ward> wrote:
> On Sat, 05 Mar 2005 11:31:03 +1300, Regan Heath wrote:
>
>> On Fri, 04 Mar 2005 19:52:38 +0100, Jan-Eric Duden <jeduden@whisset.com>
>> wrote:
>>> Anders F Björklund wrote:
>>>> Jan-Eric Duden wrote:
>>>>
>>>>>> Strings in D are protected from overwriting by the Honor System™...
>>>>>
>>>>>
>>>>> How can a D coder know if it is safe to store just the reference or if
>>>>> he needs to make a copy.
>>>>> Right now, to be on the safe side - he actually needs to make a copy.
>>>>> Otherwise, somewhere in her system or in external libraries the string
>>>>> might get changed without her knowledge.
>>>>   Copy-on-Write and immutable strings have a great advantage over
>>>> deep copying and mutable strings, both when it comes to performance
>>>> and when it comes to thread-safety (avoiding locks is also performance)
>>>>  Along with slices and garbage collection, it gives D great speed...
>>>>  What is needed is a method in the language to make sure that this
>>>> is enforced, when passing arrays to other modules and functions ?
>>>> Without it, as you say, strings *could* be modified by the method.
>>>>  But I'm still hoping that it can be done without const / class...
>>>>  --anders
>>>>  PS. See also the "immutable strings" thread, and others like it.
>>> If i can get immutable string without a class and const, I'd be happy.:)
>>>
>>> I wonder how this can be implemented without one of these concepts?
>>
>> I think the first step is enforcing 'constness' on 'in' parameters.
>>
>> That will basically say, for this function:
>>    void foo(char[] a, inout char[] b);
>>
>> a will not be modified, b might be modified.
>>
>> It's a contract. It needs to be enforced.
>
> It is enforced - 'a' itself is not modified.

No, 'technically' it's not enforced. If it were enforced the compiler would give an error when you modifed the 'reference' itself (not shown in my example), it doesn't. It only _seems_ to enforce it because it makes a copy of the reference for the function call. Is the fact that it makes a copy specified or simply what happens in this compiler?

> However, whatever 'a' refers
> to may be modified.

True. There is a distinction.

> import std.stdio;
> void foo(char[] a, inout char[] b) { a = "abc"; b = "def"; }
> void main()
> {
>   char[] X = "123";
>   char[] Y = "456";
>   writefln("before X=%s, Y=%s", X, Y);
>   foo(X, Y);
>   writefln(" after X=%s, Y=%s", X, Y);
> }
>
> So what we need to be able to express, is a way to tell the compiler that
> the data referred to is not to be modified, and not just the referrer.

Sure, but, the concept I'm really after is simply "I am _only_ going to read from this variable", for that to be true/expressed the only operation permissable on the variable would be a read operation, not a write operation.

If this concpet can be realised then "Copy On Write" can be done much more surely/safely.

Regan

On Fri, 4 Mar 2005 17:48:45 -0500, Ben Hinkle <bhinkle@mathworks.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opsm4wt1uo23k2f5@ally...
>> On Fri, 04 Mar 2005 19:52:38 +0100, Jan-Eric Duden <jeduden@whisset.com>
>> wrote:
>>> Anders F Björklund wrote:
>>>> Jan-Eric Duden wrote:
>>>>
>>>>>> Strings in D are protected from overwriting by the Honor SystemT...
>>>>>
>>>>>
>>>>> How can a D coder know if it is safe to store just the reference or if
>>>>> he needs to make a copy.
>>>>> Right now, to be on the safe side - he actually needs to make a copy.
>>>>> Otherwise, somewhere in her system or in external libraries the string
>>>>> might get changed without her knowledge.
>>>>   Copy-on-Write and immutable strings have a great advantage over
>>>> deep copying and mutable strings, both when it comes to performance
>>>> and when it comes to thread-safety (avoiding locks is also performance)
>>>>  Along with slices and garbage collection, it gives D great speed...
>>>>  What is needed is a method in the language to make sure that this
>>>> is enforced, when passing arrays to other modules and functions ?
>>>> Without it, as you say, strings *could* be modified by the method.
>>>>  But I'm still hoping that it can be done without const / class...
>>>>  --anders
>>>>  PS. See also the "immutable strings" thread, and others like it.
>>> If i can get immutable string without a class and const, I'd be happy.:)
>>>
>>> I wonder how this can be implemented without one of these concepts?
>>
>> I think the first step is enforcing 'constness' on 'in' parameters.
>>
>> That will basically say, for this function:
>>   void foo(char[] a, inout char[] b);
>>
>> a will not be modified, b might be modified.
>>
>> It's a contract. It needs to be enforced.
>>
>> Regan
>>
>
> Changing the semantics of "in" to also apply to references would be a huge change and it would go against the default semantics of C.

True.

> A (slightly) more
> practical proposal is to have parameters explicitly declared as "in" be
> read-only but even then it would be a big change and we'd have to think
> about how the read-only-ness would be represented in the type and passed
> along to other variables.

I dislike this. I think by default variables should be 'read-only' or 'const', the programmer should have to specifically denote the ones they want to modify (using out, inout), not the other way around.

> Basically I think the only real way to add this to D if it ever gets added is to have another type attribute like C/C++'s
> const.
>
> Note that there really isn't anything special about strings, too. Any type with reference semantics is at the mercy of the functions it gets passed to.

Exactly. The concept/contract I want is "I am only going to read from this variable", and I want it enforced.
Using the reference to write to the data it refers to is a write operation, and should be denied.

> Class objects, arrays in general, etc. They all rely on implicit contracts that the functions do what they say they do.

If the contract was enforced, then you could be more sure/safe using "Copy On Write".

Regan

"Craig Black" <cblack@ara.com> wrote in message news:d0b1b7$2g4b$1@digitaldaemon.com...
> Do dynamic arrays in D do automatic resizing like std::vector in C++?

Yes.

> If  not, a vector template would be useful.

D arrays are far more flexible than std::vector. Try doing a slice of an std::vector <g>. Yes, I know there's a slice class, too, but it leaves memory ownership issues unresolved.

>> If  not, a vector template would be useful.
>
> D arrays are far more flexible than std::vector. Try doing a slice of an std::vector <g>. Yes, I know there's a slice class, too, but it leaves memory ownership issues unresolved.

Walter, may I ask you:
who wrote this: "Resizing a dynamic array is a relatively expensive
operation."?
IMO, std::vectors are all about this.

BTW: There is std::vector::insert operation which is not covered in D yet.

In fact I've made a poll among companies (9) which do C++ seriously (very).

4 of them do not use STL at all
1 uses their own clone of STL due to lack of some features in foundation.
1 uses STL in full and there STL is a must - at corporate policy level.
2 use STL just for std::vector and simple stuff like min/max.

As a rule STL is used in projects with stream processing style systems. Sort of stdin -> stdout. UI dictates different policies - UI frameworks has their own CArray/CString, etc. optimized for the target.

D does basic STL functionality in its core and this is extremely good, IMO.

I was "totally sliced" by the D slicing first time. But second time I've got your point and learned word 'dup' :)

BTW, gentlemen, I've attached extremely simple (thanks to D)
class array(T) {...} implementation
and would like to hear any comments/critics about it before diving any
deeper.

Andrew Fedoniouk.
http://terrainformatica.com

> Since strings are so fundamental, there should be a single standardized string interface. It needs to be powerful enough so that there is no reason for anyone to develop a second string class for purpose x.

In my HTML engines (latest is
http://terrainformatica.com/hsmile/hsmilesdk.zip )
I am using two my own string classes: string and ustring (unicode string).
For example HTML DOM element attribute name is string,
its value is ustring. This is all about effectivnes and memory consumption.

As more I am looking in D as more I am thinking that
string as char[] or wchar[]  (D automatic arrays) is a way to go.
It is a best compromise what you can reach.
Strings are dual in their nature: they are atomic (value) type and an
object with many methods derived from vector + their specific methods.

You can define "external methods" for e.g. wchar[] thus to build a string
class
for target task in most optimal way.

E.g. something like:

alias wchar[] string;
bool like(string s, string pattern);

to call it as:
string mystr;

if( mystr.like("foo*") )
   ....

It's a pitty that "external methods" works only for arrays. I would like to extend them for all basic types. At least to be able to write T.toString() in templates.

int i = 23; string s = i.toString();

Andrew Fedoniouk.
http://terrainformatica.com

"I very much dislike choice of having JAVA-like functionNames"

I am with you, Dejan :)

But notation style is always a subject of holy wars.
Language itself should be agnostic to that matter and this is it.

<lyrics>
Anyone is free to write by right hand or by left hand.
In the Middle East they use even "wrong direction" and nobody
complain about that (except of designers of HTML
engines of course :)
</lyrics>

Andrew Fedoniouk.
http://terrainformatica.com




"Dejan Lekic" <leka@entropy.tmok.com> wrote in message news:d086f9$2kbb$1@digitaldaemon.com...
>
> I very much dislike choice of having JAVA-like functionNames... That might
> even come to turning back to D. :( I thought pretty much about resons
> behind using that naming convention and there was none good reason i could
> come to. Seriously.
> Someone pointed out that people use it to distinct from class-names. Well,
> if i have dot (".") before it, it cannot be the class! :)
> Anyway it's up to D developers and they made their decision - this is just
> a
> personal note.
> I prefer MethodNames() or method_names() . methodNames() are unacceptable
> for my projects. :)
> IMHO it would be good if D doesn't make difference between those somehow.
> :)
>
> Kind regards
>
> -- 
> ...........
> Dejan Lekic
>  http://dejan.lekic.org
> 

Andrew Fedoniouk wrote:
> BTW, gentlemen, I've attached extremely simple (thanks to D)
> class array(T) {...} implementation
> and would like to hear any comments/critics about it before diving any deeper.
> 
> Andrew Fedoniouk.
> http://terrainformatica.com

One suggestion after a quick glance of your neat code:
make the gc happy at line 69.

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d0e84a$2aie$1@digitaldaemon.com...
>>> If  not, a vector template would be useful.
>>
>> D arrays are far more flexible than std::vector. Try doing a slice of an std::vector <g>. Yes, I know there's a slice class, too, but it leaves memory ownership issues unresolved.
>
> Walter, may I ask you:
> who wrote this: "Resizing a dynamic array is a relatively expensive
> operation."?
> IMO, std::vectors are all about this.
>
> BTW: There is std::vector::insert operation which is not covered in D yet.
>

You can do:

myArray = myArray [0..insertIndex].dup ~ newElement ~ myArray [insertIndex..length].dup; // Not sure if I need the '.dup's

I'm not sure how the performance compares to std::vector::insert though.


> In fact I've made a poll among companies (9) which do C++ seriously (very).
>
> 4 of them do not use STL at all
> 1 uses their own clone of STL due to lack of some features in foundation.
> 1 uses STL in full and there STL is a must - at corporate policy level.
> 2 use STL just for std::vector and simple stuff like min/max.
>
> As a rule STL is used in projects with stream processing style systems. Sort of stdin -> stdout. UI dictates different policies - UI frameworks has their own CArray/CString, etc. optimized for the target.
>
> D does basic STL functionality in its core and this is extremely good, IMO.
>
> I was "totally sliced" by the D slicing first time. But second time I've
> got
> your point and learned word 'dup' :)
>
> BTW, gentlemen, I've attached extremely simple (thanks to D)
> class array(T) {...} implementation
> and would like to hear any comments/critics about it before diving any
> deeper.
>
> Andrew Fedoniouk.
> http://terrainformatica.com
>
>
>
>
>
>
>