November 20, 2012
> 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
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
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
Is there an official statement why Walter dislike them?
November 21, 2012
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
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
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
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.
1 2
Next ›   Last »