>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.

Agreed. except that unless i missed something, core language does not handle lists, stacks, and queues.

Having strings, vectors, hashmaps, and foreach IS nice, but I'd also like to see the other three basic containers I just mentioned in a 1.0 version.

To me, as far as templates are concerned, every thing else can wait. (But of course, I won't complain if more is included.)

Thanks, Nick, for your comments

I don't think that you need dups here if I understand this mechanics:

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

But in any case it will create brand new myArray each time.
For use cases with frequent insertions this is non acceptable I think.

Andrew.

Regan Heath wrote:
> 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".

I've always felt this is an, at best, diffuse subject. I'd like to clarify (at least for myself :-)  ) what we are discussing. I see so many different ways to look at it.

- COW may either be
  - enforced totally by the compiler/language
    - either totally (definitely not D here)
    - enforce, but with back doors ("if you really want")
  - make it easy to do and support it
  - just give opportunities and some help
- or
  - not stand in the way if someone tries to follow it
  - not give a damn, let programmer do the cows by himself
  - make it hard (by implicit cow somewhere and not when you expect)

What is the consensus (or is there) on where we
  - are now
  - would like to be?

On another plane, who's responsible for cow? Should it be entirely the programmer or entirely the compiler/language? Where do we want to be, or should want to be, on this scale?

Part of my problem lies with not having done so much Java &co that I'd have become immersed or dependent on this. When I programmed in Pascal, it was your call all the way. Or, rather, one never thought about it. Why make things grander and more compicated.

(I've got automatic indoor temperature in my car. It meticulously measures temperature here and there, and tries to reach some level it believes I want. Well, my wants depend on so many things, like what I'm wearing, whether I walked quickly to the car, whatever. My old car only had three knobs: where, fan speed, and heat. They reacted instantly, and I knew what to turn and when, without thinking.)

Pascal had in, inout, and out parameters. Could it be that this is the level that gives the optimum between coding speed, reliability, practicality -- vs -- complicity of compiler as well as usage, or conceptual intractability. Or at least an increased need to resort to documentation?

(removed .dtl group from this reply.. why are we posting to both groups??)

On Mon, 07 Mar 2005 14:03:21 +0200, Georg Wrede <georg.wrede@nospam.org> wrote:
> I've always felt this is an, at best, diffuse subject. I'd like to clarify (at least for myself :-)  ) what we are discussing. I see so many different ways to look at it.
>
> - COW may either be
>    - enforced totally by the compiler/language
>      - either totally (definitely not D here)
>      - enforce, but with back doors ("if you really want")
>    - make it easy to do and support it
>    - just give opportunities and some help
> - or
>    - not stand in the way if someone tries to follow it
>    - not give a damn, let programmer do the cows by himself
>    - make it hard (by implicit cow somewhere and not when you expect)
>
> What is the consensus (or is there)

I doubt it :)

> on where we
>    - are now

"not stand in the way if someone tries to follow it"

>    - would like to be?

"make it easy to do and support it"

> On another plane, who's responsible for cow? Should it be entirely the programmer or entirely the compiler/language?

Neither.

> Where do we want to be, or should want to be, on this scale?

I think the programmer is responsible for it, they choose where/when to use it, and where/when not to use it. At the same time the language should not make it difficult to use, it should attempt to prevent 'bad code' from breaking COW.

> Part of my problem lies with not having done so much Java &co that I'd have become immersed or dependent on this. When I programmed in Pascal, it was your call all the way. Or, rather, one never thought about it. Why make things grander and more compicated.
>
> (I've got automatic indoor temperature in my car. It meticulously measures temperature here and there, and tries to reach some level it believes I want. Well, my wants depend on so many things, like what I'm wearing, whether I walked quickly to the car, whatever. My old car only had three knobs: where, fan speed, and heat. They reacted instantly, and I knew what to turn and when, without thinking.)
>
> Pascal had in, inout, and out parameters. Could it be that this is the level that gives the optimum between coding speed, reliability, practicality -- vs -- complicity of compiler as well as usage, or conceptual intractability. Or at least an increased need to resort to documentation?

How did pascal implement in, inout and out? Did it enforce read-only on 'in'? or..

Regan

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d0fi39$fsd$1@digitaldaemon.com...

> I don't think that you need dups here if I understand this mechanics:
>
> > myArray = myArray [0..insertIndex].dup ~ newElement ~ myArray [insertIndex..length].dup; // Not sure if I need the '.dup's

The .dup is unnecessary here.

> But in any case it will create brand new myArray each time.

No. It uses a heuristic to avoid doing this most of the time.

> For use cases with frequent insertions this is non acceptable I think.

Walter wrote:
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:d0fi39$fsd$1@digitaldaemon.com...
> 
>> I don't think that you need dups here if I understand this
>> mechanics:
>> 
>>> myArray = myArray [0..insertIndex].dup ~ newElement ~ myArray [insertIndex..length].dup; // Not sure if I need the '.dup's
> 
> The .dup is unnecessary here.
> 
>> But in any case it will create brand new myArray each time.
> 
> No. It uses a heuristic to avoid doing this most of the time.
> 
>> For use cases with frequent insertions this is non acceptable I
>> think.

This is one of two ways to insert in an array.  The other is

    uint len = newElement.length;
    myArray.length = myArray.length + len;
    myArray[insertIndex+len..length]
      = myArray[insertIndex..length-len].dup;
    myArray[insertIndex..insertIndex+len] = newElement;

Does DMD optimise the above to something like this?

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on
the 'group where everyone may benefit.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:d0kji1$2pt6$1@digitaldaemon.com...
> This is one of two ways to insert in an array.  The other is
>
>      uint len = newElement.length;
>      myArray.length = myArray.length + len;
>      myArray[insertIndex+len..length]
>        = myArray[insertIndex..length-len].dup;
>      myArray[insertIndex..insertIndex+len] = newElement;
>
> Does DMD optimise the above to something like this?

I'm not sure what's going on in that snippet <g>, but all the D runtime does is have an 'allocated' size for each array, which is >= the .length. The allocated size goes up by powers of 2. The array doesn't need to be reallocated if there is enough space in the allocated size to handle the increase.

On Wed, 9 Mar 2005 16:07:09 -0800, Walter <newshound@digitalmars.com> wrote:
> "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message
> news:d0kji1$2pt6$1@digitaldaemon.com...
>> This is one of two ways to insert in an array.  The other is
>>
>>      uint len = newElement.length;
>>      myArray.length = myArray.length + len;
>>      myArray[insertIndex+len..length]
>>        = myArray[insertIndex..length-len].dup;
>>      myArray[insertIndex..insertIndex+len] = newElement;
>>
>> Does DMD optimise the above to something like this?
>
> I'm not sure what's going on in that snippet <g>, but all the D runtime does
> is have an 'allocated' size for each array, which is >= the .length. The
> allocated size goes up by powers of 2. The array doesn't need to be
> reallocated if there is enough space in the allocated size to handle the
> increase.

I know this has been mentioned before, but... Can we get a 'reserve' method/property. eg.

  array.reserve = 1,000,000;

Which would essentially cause:

  len = array.length;
  array.length = 1,000,000;
  array.length = len;

Allowing us to reserve space before doing a large number of concatentations (for example).
Obviating the need for 3 lines of code and a temp var.

It can still, and should still allocate in powers of 2, it just allocates to the power of 2 greater than the value specified.

Another question, does the 'allocated' size ever decrease?
If so, when?
Is it possible for it to decrease while 1/2 way thru a large number of concatentions.

Regan

In article <opsnejj4bk23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Wed, 9 Mar 2005 16:07:09 -0800, Walter <newshound@digitalmars.com> wrote:
>> "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:d0kji1$2pt6$1@digitaldaemon.com...
>>> This is one of two ways to insert in an array.  The other is
>>>
>>>      uint len = newElement.length;
>>>      myArray.length = myArray.length + len;
>>>      myArray[insertIndex+len..length]
>>>        = myArray[insertIndex..length-len].dup;
>>>      myArray[insertIndex..insertIndex+len] = newElement;
>>>
>>> Does DMD optimise the above to something like this?
>>
>> I'm not sure what's going on in that snippet <g>, but all the D runtime
>> does
>> is have an 'allocated' size for each array, which is >= the .length. The
>> allocated size goes up by powers of 2. The array doesn't need to be
>> reallocated if there is enough space in the allocated size to handle the
>> increase.
>
>I know this has been mentioned before, but... Can we get a 'reserve' method/property. eg.
>
>   array.reserve = 1,000,000;
>
>Which would essentially cause:
>
>   len = array.length;
>   array.length = 1,000,000;
>   array.length = len;
>
>Allowing us to reserve space before doing a large number of
>concatentations (for example).
>Obviating the need for 3 lines of code and a temp var.
>
>It can still, and should still allocate in powers of 2, it just allocates to the power of 2 greater than the value specified.
>
>Another question, does the 'allocated' size ever decrease?
>If so, when?
>Is it possible for it to decrease while 1/2 way thru a large number of
>concatentions.
>
>Regan

It's funny you mention this. I was working on adding the attached "dynamic array
with capacity" to mintl.array plus some other array helpers but since it came up
I thought I'd post about it.
Anyway, comments welcome,
-Ben

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsnejj4bk23k2f5@nrage.netwin.co.nz...
> I know this has been mentioned before, but... Can we get a 'reserve' method/property. eg.
>
>    array.reserve = 1,000,000;
>
> Which would essentially cause:
>
>    len = array.length;
>    array.length = 1,000,000;
>    array.length = len;
>
> Allowing us to reserve space before doing a large number of
> concatentations (for example).
> Obviating the need for 3 lines of code and a temp var.

Why not just write a function to do it?

> It can still, and should still allocate in powers of 2, it just allocates to the power of 2 greater than the value specified.
>
> Another question, does the 'allocated' size ever decrease?
> If so, when?
> Is it possible for it to decrease while 1/2 way thru a large number of
> concatentions.

That's at the discretion of the implementation of the gc.