November 20, 2012
Is there any need for 'smart' or 'compressed' arrays?

In my last projects I had some situations where I need an array, but only for one scope. But I could not use static arrays, because I didn't know the size at compile time. So I used 'alloca'. But 'alloca' has a terrible interface and in some few cases I had to append x elements. So I used a dynamic array. But dynamic arrays live longer as the lifetime of the scope. Furthermore dynamic arrays costs more memory as I needed, because the capacity of them is n * 2 + 1, but in my cases I need only n.
So what I need was an array, which lives only for one scope (freed memory after leaving scope) and which hasn't more elements/capacity as I need.

Am I wrong and dynamic arrays are the solution? Or is there need for such 'compressed' arrays?
Another solution would be to improve the interface of alloca, but it would be still not resizable.
November 20, 2012
Namespace:

> Furthermore dynamic arrays costs more memory as I needed,

But maybe this doesn't happen in your case.


> Am I wrong and dynamic arrays are the solution?

Take also a look at the Array of Phobos.

Bye,
bearophile
November 20, 2012
On 11/20/2012 06:25 AM, Namespace wrote:
> Is there any need for 'smart' or 'compressed' arrays?
>
> In my last projects I had some situations where I need an array, but
> only for one scope. But I could not use static arrays, because I didn't
> know the size at compile time. So I used 'alloca'. But 'alloca' has a
> terrible interface and in some few cases I had to append x elements. So
> I used a dynamic array. But dynamic arrays live longer as the lifetime
> of the scope. Furthermore dynamic arrays costs more memory as I needed,
> because the capacity of them is n * 2 + 1, but in my cases I need only n.
> So what I need was an array, which lives only for one scope (freed
> memory after leaving scope) and which hasn't more elements/capacity as I
> need.
>
> Am I wrong and dynamic arrays are the solution? Or is there need for
> such 'compressed' arrays?
> Another solution would be to improve the interface of alloca, but it
> would be still not resizable.

The following program makes a slice from GC-allocated memory (or a fixed-size array as in the comment). The important part is 'buffer[0..10]'.

import std.stdio;
import core.memory;

void bar(int[] a)  // Also try: int[10] a
{
    writeln("param : ", a.ptr);
}

void foo()
{
    int *buffer = cast(int*)GC.calloc(int.sizeof * 10);
    scope (exit) GC.free(buffer);

    writeln("buffer: ", buffer);

    int[] a = buffer[0..10];  // Also try: int[10] a =

    writeln("a     : ", a.ptr);

    foreach (i; a) {
        i = 42 + i;
    }

    bar(a);
}

void main()
{
    foo();
}

Ali
November 20, 2012
Yes, but I could also use alloca. What I mean is the shortness of int[4] arr or
for (int i = 0; i < 42; i += 4) {
    int[i] arr;
}

I take a look at the std.container Array.
November 20, 2012
Something like:
scope int[8] arr;
or
scope int[i] arr;

would be cool. You get an resizeable array which capactiy is all the time equal to his length. And it is destroyed after the liftetime of the scope.

Maybe some stuff for Remus...
November 20, 2012
On 11/20/2012 02:46 PM, Namespace wrote:
> Something like:
> scope int[8] arr;
> or
> scope int[i] arr;
>
> would be cool. You get an resizeable array which capactiy is all the
> time equal to his length. And it is destroyed after the liftetime of the
> scope.
>
> Maybe some stuff for Remus...

This is a surprisingly promising start: :)

import std.stdio;

struct FixedArray(T, size_t N)
{
    T[N] elements;
    alias elements this;
}

void main()
{
    FixedArray!(int, 10) a;

    foreach (int i, ref e; a) {
        e = 42 + i;
    }

    writeln(a);
}

Ali
November 20, 2012
Namespace:

> scope int[8] arr;
> or
> scope int[i] arr;

See also:
http://d.puremagic.com/issues/show_bug.cgi?id=5348

Bye,
bearophile
November 20, 2012
On Tuesday, November 20, 2012 23:46:39 Namespace wrote:
> Something like:
> scope int[8] arr;
> or
> scope int[i] arr;
> 
> would be cool. You get an resizeable array which capactiy is all the time equal to his length. And it is destroyed after the liftetime of the scope.
> 
> Maybe some stuff for Remus...

It's pretty trivial to create a struct which uses malloc and free to create a dynamic array of the exact size that you want with deterministic destruction, and you can easily overload the indexing and slicing operators - though clearly, as if with static arrays, you'd have to be careful with slices being passed around, since they're not owned by the GC. And I'm not sure what would happen if you were foolish enough to try and append to them.

Personally though, I wish that the length of static arrays could be set at runtime and don't really understand why you can't (aside from the fact that you can't in standard C - gcc will let you though).

- Jonathan M Davis
November 20, 2012
On Tuesday, November 20, 2012 14:52:56 Ali Çehreli wrote:
> On 11/20/2012 02:46 PM, Namespace wrote:
> > Something like:
> > scope int[8] arr;
> > or
> > scope int[i] arr;
> > 
> > would be cool. You get an resizeable array which capactiy is all the time equal to his length. And it is destroyed after the liftetime of the scope.
> > 
> > Maybe some stuff for Remus...
> 
> This is a surprisingly promising start: :)
> 
> import std.stdio;
> 
> struct FixedArray(T, size_t N)
> {
>      T[N] elements;
>      alias elements this;
> }
> 
> void main()
> {
>      FixedArray!(int, 10) a;
> 
>      foreach (int i, ref e; a) {
>          e = 42 + i;
>      }
> 
>      writeln(a);
> }

How is that any different from just using a static array? All you've done is wrap it. You still can't set its size at runtime. Isn't what the OP is essentially looking for is a static array whose length can be set at runtime? This doesn't solve that. For that, you need something which is going to allocate on the heap at runtime but deterministically free that that memory when it's done.

- Jonathan M Davis
November 20, 2012
On 11/20/2012 02:59 PM, Jonathan M Davis wrote:
> On Tuesday, November 20, 2012 14:52:56 Ali Çehreli wrote:

>> This is a surprisingly promising start: :)

> How is that any different from just using a static array?

I know, I know... That surprising start surprised me too. :p

Ali

« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home