www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - back to arays

reply Max Samuha <maxter i.com.ua_spamless> writes:



int[] a = new int[20];
int[] b = a;

a.length = 40; // a is copied and b is not updated to point to a's
data;

Does it mean that anytime i change an array, i have to manually update
all references to it or should i wrap my array in an Array class so
that all references to any instance of that array remain valid?

If the question have been already discussed please refer me to the
right thread. Thanks
May 15 2006
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 15 May 2006 10:05:22 +0300, Max Samuha <maxter i.com.ua_spamless>  
wrote:



 int[] a = new int[20];
 int[] b = a;

 a.length = 40; // a is copied and b is not updated to point to a's
 data;

 Does it mean that anytime i change an array, i have to manually update
 all references to it or should i wrap my array in an Array class so
 that all references to any instance of that array remain valid?

 If the question have been already discussed please refer me to the
 right thread. Thanks
The D philosophy is "copy on write". Whenever you have several references to the same data and you decide to write to the data, you should make a copy and write to the copy. If you want to constantly have several references to the same data then yes, you will have to update the references whenever you make change or write a class to handle that for you. Regan
May 15 2006
prev sibling next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 15 May 2006 10:05:22 +0300, Max Samuha wrote:



 
 int[] a = new int[20];
 int[] b = a;
 
 a.length = 40; // a is copied and b is not updated to point to a's
 data;
 
 Does it mean that anytime i change an array, i have to manually update
 all references to it or should i wrap my array in an Array class so
 that all references to any instance of that array remain valid?
 
 If the question have been already discussed please refer me to the
 right thread. Thanks
I assume for some valid reason you want this behaviour... int[] a = new int[20]; int[] b = a; int[] c = a; a[0] = 17; writefln("%s %s", b[0], c[0]); // Displays 17 17 The simplest way to do this is ... int[] a = new int[20]; int[]* b = &a; int[]* c = &a; a[0] = 17; writefln("%s %s", b[0], c[0]); // Displays 17 17 I'm not sure why one would need this behaviour though. Why do you need two identifiers in the same scope to reference the same data? -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 15/05/2006 5:49:08 PM
May 15 2006
parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Derek Parnell wrote:
 On Mon, 15 May 2006 10:05:22 +0300, Max Samuha wrote:
 



 int[] a = new int[20];
 int[] b = a;

 a.length = 40; // a is copied and b is not updated to point to a's
 data;

 Does it mean that anytime i change an array, i have to manually update
 all references to it or should i wrap my array in an Array class so
 that all references to any instance of that array remain valid?

 If the question have been already discussed please refer me to the
 right thread. Thanks
I assume for some valid reason you want this behaviour... int[] a = new int[20]; int[] b = a; int[] c = a; a[0] = 17; writefln("%s %s", b[0], c[0]); // Displays 17 17
But... it will display '17 17'.
 The simplest way to do this is  ...
 
  int[] a = new int[20];
  int[]* b = &a;
  int[]* c = &a;
  a[0] = 17;
  writefln("%s %s", b[0], c[0]); // Displays 17 17
Nope, the earlier one :) As I understand it, he'd like this code: to output '20 20'. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y ------END GEEK CODE BLOCK------ Tomasz Stachowiak /+ a.k.a. h3r3tic +/
May 15 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Mon, 15 May 2006 20:24:39 +1000, Tom S  
<h3r3tic remove.mat.uni.torun.pl> wrote:

 Derek Parnell wrote:
 On Mon, 15 May 2006 10:05:22 +0300, Max Samuha wrote:




 int[] a = new int[20];
 int[] b = a;

 a.length = 40; // a is copied and b is not updated to point to a's
 data;

 Does it mean that anytime i change an array, i have to manually update
 all references to it or should i wrap my array in an Array class so
 that all references to any instance of that array remain valid?

 If the question have been already discussed please refer me to the
 right thread. Thanks
I assume for some valid reason you want this behaviour... int[] a = new int[20]; int[] b = a; int[] c = a; a[0] = 17; writefln("%s %s", b[0], c[0]); // Displays 17 17
But... it will display '17 17'.
 The simplest way to do this is  ...
   int[] a = new int[20];
  int[]* b = &a;
  int[]* c = &a;
  a[0] = 17;
  writefln("%s %s", b[0], c[0]); // Displays 17 17
Nope, the earlier one :) As I understand it, he'd like this code: to output '20 20'.
That's what you get while trying to rush out of the office, late again for dinner. You are right. Here is my improved attempt and what I was trying to say earlier... import std.stdio; void main() { int[] a; int[]* b; int[]* c; b = &a; c = &a; a.length= 40; a[0] = 17; writefln("%d %d", c.length, b.length); writefln("%d %d", *c[0], *b[0]); } ------------------------- This displays 40 40 17 17 ------------------------- But I still don't know why one would want to do this? -- Derek Parnell Melbourne, Australia
May 15 2006
next sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Derek Parnell wrote:
 I'm not sure why one would need this behaviour though. Why do you need two
 identifiers in the same scope to reference the same data? 
 
Derek Parnell wrote:
 
 But I still don't know why one would want to do this?
 
I'll bet the identifiers are on the same scope just for simplification purposes. The case were you would want to have a dyn array to behave "wholly" like a reference type is quite common and necessary, just like associative arrays are now "wholly" a reference type. -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 15 2006
prev sibling parent reply Max Samuha <maxter i.com.ua_spamless> writes:
On Mon, 15 May 2006 23:08:26 +1000, "Derek Parnell" <derek psych.ward>
wrote:

void main()
{
    int[] a;
    int[]* b;
    int[]* c;

    b = &a;
    c = &a;
    a.length= 40;
    a[0] = 17;
    writefln("%d %d", c.length, b.length);
    writefln("%d %d", *c[0], *b[0]);
}

-------------------------
This displays
40 40
17 17
-------------------------

But I still don't know why one would want to do this?
No, i certainly don't want to do this. I just expected from D's dynamic arrays what was described here in a more readable English as arrays being reference types. That's clearer now. Thanks
May 15 2006
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Max Samuha wrote:
 On Mon, 15 May 2006 23:08:26 +1000, "Derek Parnell" <derek psych.ward>
 wrote:
 
 
void main()
{
   int[] a;
   int[]* b;
   int[]* c;

   b = &a;
   c = &a;
   a.length= 40;
   a[0] = 17;
   writefln("%d %d", c.length, b.length);
   writefln("%d %d", *c[0], *b[0]);
}

-------------------------
This displays
40 40
17 17
-------------------------

But I still don't know why one would want to do this?
No, i certainly don't want to do this. I just expected from D's dynamic arrays what was described here in a more readable English as arrays being reference types. That's clearer now. Thanks
I have made some similar mistakes before, to be sure. Essentially D's arrays are really structures, one of the fields of which being a pointer to the real data. Sometimes this means another array variable will be pointing to the same data, but this leaves you when you try to muck with the array. Although, in some (not all) cases you can get behavior like what you want by using inout parameters (or pointers), and in some other cases (still not all) you could probably use slice semantics. -- Chris Nicholson-Sauls
May 15 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Tom S wrote:
 
 
 As I understand it, he'd like this code:
 




 
 to output '20 20'.
 
 
You mean "to output '10 10'", no? -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 15 2006
parent Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Bruno Medeiros wrote:
 You mean "to output '10 10'", no?
Arrrgh you're right :S -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d-pu s+: a-->----- C+++$>++++ UL P+ L+ E--- W++ N++ o? K? w++ !O !M V? PS- PE- Y PGP t 5 X? R tv-- b DI- D+ G e>+++ h>++ !r !y ------END GEEK CODE BLOCK------ Tomasz Stachowiak /+ a.k.a. h3r3tic +/
May 15 2006
prev sibling next sibling parent Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Max Samuha skrev:


 
 int[] a = new int[20];
 int[] b = a;
 
 a.length = 40; // a is copied and b is not updated to point to a's
 data;
 
 Does it mean that anytime i change an array, i have to manually update
 all references to it or should i wrap my array in an Array class so
 that all references to any instance of that array remain valid?
 
 If the question have been already discussed please refer me to the
 right thread. Thanks
The behavior of D's built in arrays have been the cause of much confusion. D's arrays actually have a kind of schizophrenic nature. They are value types referring to some portion of memory, and as such, they are not pure arrays (of course a matter of interpretation), but rather array slices. On the other hand they support append operations, and automatically copy and reallocate the data when the length is increased, which doesn't make sense for a pure slice type. So in the sense of being arrays, D's arrays neither fulfill the expected semantics of being a value type nor a reference type. This will probably make many D users cringe, by my suggestion is to use an array wrapper type with reference semantics. Something like this: (untested and incomplete code) class Array(T) { T[] data; this() {} this(int n) { length(n); } this(T[] data) { this.data = data; } void length(size_t n) { data.length = n; } size_t length() { return data.length; } Array dup() { return new Array(data.dup); } T opIndex(size_t i) { return data[i]; } T opIndexAssign(T v, size_t i) { return data[i] = v; } T[] opSlice(size_t a, size_t b) { return data[a..b]; } int opApply(...) {...} } Usage: Array!(int) a = new Array!(int)(20); Array!(int) b = a; a.length = 40; // a is NOT copied and b is updated to point to a's data Properly implemented this will work as you expect with one caveat. There is no reference return type for opIndex, making arrays of structs somewhat inconvenient. I think you can find a proper implementation in the ancient DTL library. Regards, Oskar
May 15 2006
prev sibling parent reply James Pelcis <jpelcis gmail.com> writes:
You can always "cheat" and do:

alias a b;

Max Samuha wrote:


 
 int[] a = new int[20];
 int[] b = a;
 
 a.length = 40; // a is copied and b is not updated to point to a's
 data;
 
 Does it mean that anytime i change an array, i have to manually update
 all references to it or should i wrap my array in an Array class so
 that all references to any instance of that array remain valid?
 
 If the question have been already discussed please refer me to the
 right thread. Thanks
May 15 2006
parent reply Max Samuha <maxter i.com.ua_spamless> writes:
There's one more question about arrays.

From D specs:

A pointer to the start of a garbage collected object need not be maintained if
a pointer to the interior of the object exists.
char[] p = new char[10];
char[] q = p[3..6];
// q is enough to hold on to the object, don't need to keep
// p as well.
If the garbage collector moves data referenced by p, i guess all pointers to slices of p will be updated correctly. What if i set p to null or p goes out of scope and q is still reachable, will the memory (before q.ptr and after q.ptr + q.length - 1) that was pointed to by p be reclaimed by the garbage collector?
May 17 2006
parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
I should note, currently, DMD's implementation won't move anything 
you're pointing to.

And... as you probably know, memory is allocated in chunks from the 
operating system.  Without making a copy, you can't deallocate just one 
part.  So DMD won't currently.

However, if the memory were to be copied I'd expect it to be perfectly 
reasonable that the GC might not keep the old array data (although that 
would certainly be non-trivial for the GC to do.)

I wouldn't depend on it - and it seems brittle anyway, even if it were 
guaranteed.

-[Unknown]


 There's one more question about arrays.
 
 From D specs:
 
 A pointer to the start of a garbage collected object need not be maintained if
a pointer to the interior of the object exists.
 char[] p = new char[10];
 char[] q = p[3..6];
 // q is enough to hold on to the object, don't need to keep
 // p as well.
If the garbage collector moves data referenced by p, i guess all pointers to slices of p will be updated correctly. What if i set p to null or p goes out of scope and q is still reachable, will the memory (before q.ptr and after q.ptr + q.length - 1) that was pointed to by p be reclaimed by the garbage collector?
May 17 2006
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 17 May 2006 22:07:12 -0700, Unknown W. Brackets wrote:

 I should note, currently, DMD's implementation won't move anything 
 you're pointing to.
Even if the length is increased beyond the size that has been allocated for a dynamic array? I thought that DMD allocated a new block of the right size and copied data from the old block to it then released the old block back to the GC. I think that if the length is decreased then no copying goes on and that no memory is released back to the GC, but can be later reused if the length then is increased anywhere up to the original allocation size. -- Derek (skype: derek.j.parnell) Melbourne, Australia "Down with mediocracy!" 18/05/2006 3:20:14 PM
May 17 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Derek Parnell wrote:
 On Wed, 17 May 2006 22:07:12 -0700, Unknown W. Brackets wrote:
 
 I should note, currently, DMD's implementation won't move anything 
 you're pointing to.
Even if the length is increased beyond the size that has been allocated for a dynamic array? I thought that DMD allocated a new block of the right size and copied data from the old block to it then released the old block back to the GC.
Yes, that's what it does, but that resizing results from an explicit programmer action, and not from the GC. When W. Brackets mentioned "DMD's implementation" I believe he meant the GC only, which, as is known, indeed doesn't currently move anything.
 I think that if the length is decreased then no copying goes on and that no
 memory is released back to the GC, but can be later reused if the length
 then is increased anywhere up to the original allocation size.
 
-- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
May 18 2006
parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Right, sorry if I was unclear.

When you resize an array, it makes a copy - it still doesn't move 
anything.  When I was talking about moving, I was meaning a compacting 
(defragmenting) garbage collector.

DMD's garbage collector holds onto any pointer references which are 
still active, even if you change the length of a dynamic array - so that 
issue shouldn't affect this.

For slices to work properly, the above must be guaranteed afaik.  But 
holding onto the memory around said slices need not be guaranteed.

PS: I've been called a lot of different things (Uncle Brackets, Big U, 
etc.), but I hadn't ever heard "W. Brackets".  Heh.

-[Unknown]


 Derek Parnell wrote:
 On Wed, 17 May 2006 22:07:12 -0700, Unknown W. Brackets wrote:

 I should note, currently, DMD's implementation won't move anything 
 you're pointing to.
Even if the length is increased beyond the size that has been allocated for a dynamic array? I thought that DMD allocated a new block of the right size and copied data from the old block to it then released the old block back to the GC.
Yes, that's what it does, but that resizing results from an explicit programmer action, and not from the GC. When W. Brackets mentioned "DMD's implementation" I believe he meant the GC only, which, as is known, indeed doesn't currently move anything.
May 19 2006