View mode: basic / threaded / horizontal-split · Log in · Help
November 20, 2012
Re: runtime static arrays
> 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

Yeah, but it's inconvenient to use a struct instead of a built in 
solution. ;)
November 20, 2012
Re: runtime static arrays
On Wednesday, November 21, 2012 00:30:16 Namespace wrote:
> Yeah, but it's inconvenient to use a struct instead of a built in
> solution. ;)

But if the built-in solution doesn't do what you want, then that's what you 
have to do. And the only built-in solutions are to either have a static array 
where you know its length at compile time or to use dynamic arrays, whose 
memory would be managed by the GC and which would allocate extra memory beyond 
the end of the array in order to make appending efficient. If either of those 
are fine, then there you go. But if they're not fine, then you need to find 
another solution. std.container.Array is closer to what you seem to want, but 
it would also allocate extra memory (it should have deterministic destruction 
though, since it uses malloc and free internally). To do exactly what you want 
would require creating your own type.

- Jonathan M Davis
November 21, 2012
Re: runtime static arrays
Jonathan M Davis:

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

Variable Length Arrays are part of the standard in C since C99, 
and they are in C11 still.

D doesn't have VLAs, I have asked for them since lot of time. I 
don't know why Walter doesn't like them. After using Ada language 
a little, I believe that stack allocation is very useful when you 
want to write fast code.

VLAs are a little unsafe in D because they are not on the heap, 
but a good type system is able to make them safe (some kind of 
static region analysis, done by the Rust language compiler, not 
present in D).

Beside the problem of memory ownership, and problems with stack 
overflows, there are other problems with VLAs, like how the D 
type system has to denote them, and how to move them around. How 
do you return them? Some considerations:


void foo(int n) {
    int[](n) data; // D VLA syntax?
    static assert(sizeof(data) = sizeof(size_t)); // 1 word?
    static assert(is(typeof(data) == int()));
    bar(data); // OK, decays to dynamic array
    bar(data.dup); // OK, dup turns it on a heap allocated 
dynamic array
    spam(data); // probably not allowed.
}
void bar(int[] a) {}
void spam(int[10] b) {}
void baz(int() c) {} // not allowed syntax.


Here I have used a different syntax because I think there is a 
problem with using the normal syntax: D performs CTFE when you 
call a function in a context that asks for a compile-time result 
value. Currently static array definitions require a compile-time 
value, so they induce CTFE. If D gains VLAs stack arrays can be 
created with a run-time size too, so how does the compiler knows 
if you want CTFE and to create a fixed array or you want to call 
the function at runtime and create a VLA? A different syntax 
avoids this problem.

VLAs are meant only for automatic variables, you can't put one of 
them in structs or class instances, or in global scope. Also a 
VLA decades in a dynamic array with dup or to fixed size whem 
given to a function with fixed sized argument, so you can't pass 
VLA around.

One advantage of VLA is a less bug-prone syntax compared to 
alloca(), expecially when you want 2D, 3D, etc VLA array.

C++11 has not introduced VLA for unclear reasons, but probably 
one reason was to not add more complexities. In the D type system 
there are dynamic arrays, so the situation is better.

Maybe some kind of VLAs will be present in C++14, according to 
what the C++ committee says.

Bye,
bearophile
November 21, 2012
Re: runtime static arrays
Is there an official statement why Walter dislike them?
November 21, 2012
Re: runtime static arrays
Namespace:

> Is there an official statement why Walter dislike them?

In the last years I remember no comments from him about this 
topic. But he has not closed my enhancement request.

Bye,
bearophile
November 21, 2012
Re: runtime static arrays
On Wednesday, November 21, 2012 02:26:35 bearophile wrote:
> Namespace:
> > Is there an official statement why Walter dislike them?
> 
> In the last years I remember no comments from him about this
> topic. But he has not closed my enhancement request.

One serious problem posed by them is that the size then can't be part of the 
type, meaning that you can't possibly pass them around. If you did, you'd just 
be passing dynamic arrays around. You'd have the same problem with them with 
templates - everything instantiated with them would have to be instantiated as 
a dynamic array, which could cause problems.

So, while in principle, I like the idea of being able to have the size of a 
static array determined when it's created, there are definitely problems with 
doing that once you start getting into the details of what that would mean.

- Jonathan M Davis
November 21, 2012
Re: runtime static arrays
Jonathan M Davis:

> One serious problem posed by them is that the size then can't 
> be part of the
> type, meaning that you can't possibly pass them around. If you 
> did, you'd just
> be passing dynamic arrays around.

Take a look at my code, few posts above. When a VLA is passed to 
a function, it "decays" to a dynamic array.


> You'd have the same problem with them with
> templates - everything instantiated with them would have to be 
> instantiated as
> a dynamic array, which could cause problems.

Templates will support arrays, they already do partially.

Kind of arrays and templates are two orthogonal things. What 
matters for templates is the a value is known at compile time or 
not. So I think this is not a problem.


> there are definitely problems with
> doing that once you start getting into the details of what that 
> would mean.

I agree there are some problems. But I think they aren't hard 
problems to solve.

Bye,
bearophile
November 21, 2012
Re: runtime static arrays
On 11/20/2012 11:56 PM, Jonathan M Davis wrote:
> ...
> 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.
> ...

It works as expected. A new GC-managed slice is created.
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home