www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Explicit Slicing of std.container.Array

reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
Is there a reason why std.container.Array have to be explicitly 
sliced before being processed by range algorithms such as filter 
typically as

     import std.container: Array;
     Array!int a;
     foreach (e; a[].filter!"true") {}

?

Does memory allocation play a role?

I would like to see it be used in replace of D builtin arrays 
without any code changes.
Jan 24 2015
next sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
On Saturday, 24 January 2015 at 13:11:33 UTC, Nordlöw wrote:

 Is there a reason why std.container.Array have to be explicitly 
 sliced before being processed by range algorithms such as 
 filter typically as

     import std.container: Array;
     Array!int a;
     foreach (e; a[].filter!"true") {}

 ?

 Does memory allocation play a role?

 I would like to see it be used in replace of D builtin arrays 
 without any code changes.


Because container are no ranges. If they were ranges, what would 
array.popFront() do?
Jan 24 2015
parent reply =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
On Saturday, 24 January 2015 at 13:59:13 UTC, Tobias Pankrath 
wrote:

    foreach (e; a[].filter!"true") {}




Is a[] a no-op if a is a D normal builtin array/slice?
Jan 24 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Sat, 24 Jan 2015 19:51:30 +0000, Nordl=C3=B6w wrote:


 On Saturday, 24 January 2015 at 13:59:13 UTC, Tobias Pankrath wrote:

    foreach (e; a[].filter!"true") {}




=20
 Is a[] a no-op if a is a D normal builtin array/slice?


yes. the following source produces the same machine code regardless of=20
slicing on `z` with 'dmd -c':

  usize test (int[] a) { return a.length; }

  int main () {
    int[] z =3D new int[](4);
    z[0] =3D 42;
    z[3] =3D 666;
    return test(z[]);
  }
=
Jan 24 2015
parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
On Saturday, 24 January 2015 at 21:10:29 UTC, ketmar wrote:

 yes. the following source produces the same machine code 
 regardless of
 slicing on `z` with 'dmd -c':


Nice, that's what I had hoped for! Thanks.
Jan 24 2015
prev sibling next sibling parent reply "Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:
On Saturday, 24 January 2015 at 13:11:33 UTC, Nordlöw wrote:

 Is there a reason why std.container.Array have to be explicitly 
 sliced before being processed by range algorithms such as 
 filter typically as

     import std.container: Array;
     Array!int a;
     foreach (e; a[].filter!"true") {}

 ?

 Does memory allocation play a role?

 I would like to see it be used in replace of D builtin arrays 
 without any code changes.


One thing to mention in the revised docs in the introduction to 
std.algorithms.
Jan 24 2015
parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
On Saturday, 24 January 2015 at 15:30:36 UTC, Laeeth Isharc wrote:

 One thing to mention in the revised docs in the introduction to 
 std.algorithms.


https://github.com/D-Programming-Language/phobos/pull/2904

Thanks!
Jan 24 2015
prev sibling parent Jonathan M Davis via Digitalmars-d-learn writes:
On Saturday, January 24, 2015 13:11:31 Nordlöw via Digitalmars-d-learn wrote:

 Is there a reason why std.container.Array have to be explicitly
 sliced before being processed by range algorithms such as filter
 typically as

      import std.container: Array;
      Array!int a;
      foreach (e; a[].filter!"true") {}

 ?

 Does memory allocation play a role?

 I would like to see it be used in replace of D builtin arrays
 without any code changes.


Dynamic arrays are an odd beast in that they're sort of containers and sort
of not, because they don't really manage their own memory. Either they're a
slice of the stack, manually managed memory, or from GC-allocated memory.
So, really, it's what they're a slice of that manages the memory. And when
you do stuff like ~=, then GC is what takes care of it (possibly
reallocating the memory as GC-allocated memory even if it referred to
manually-allocated memory before). But the dynamic array itself does not. It
doesn't manage memory any more than a pointer does. Just like incrementing a
pointer doesn't involve managing memory, calling popFront on an dynamic
array doesn't manage memory. It just changes exactly which piece of memory
you're looking at. So, a dynamic array can function as a range.

In contrast, an actual container like std.container.Array _does_ manage its
memory. And calling popFront on it would be nonsensical. It's not a range
and shouldn't be one. So, it's just not going to work to expect a container
to function in exactly the same code that a dynamic array does. It would be
closer to expect the range over a container to operate like a dynamic array
does, but even then, that doesn't quite work, because dynamic arrays have
operations which aren't range-based (like ~ and ~=), because they're a weird
special case that's kind of trying to be a container without actually being
a container.

It will work far better if your generic code is written to operate on ranges
or on containers and _not_ dynamic arrays. If it's written to operate on
ranges, then both arrays and a range over a container or any other kind of
range will work with that code, whereas if it's written to work with a
container, then it will work with whatever has the appropriate API - which
_can_ be a dynamic array under a restricted set of operations, but
frequently won't be. Restricting yourself to using [] on the container
_would_ make it work with dynamic arrays, and some functions like remove
might work, but you do have to be a bit careful when trying to use dynamic
arrays and containers interchangebly, because dynamic arrays really aren't
proper containers. Static arrays are actually closer, but they're value
types, whereas containers will normally be reference types, so passing them
around will have different semantics.

Dynamic arrays in D are kind of weird beasts. They're _very_ useful the way
that they are, but their quirkiness can be problematic if you're not
careful, and the fact that they're _sort of_ containers but not is
definitely one place that throws people off.

- Jonathan M Davis
Jan 24 2015