Due to compatibility with some C code, I basically need to do this:

    struct Wrapper
    {
        int[] x;
    }

    void main()
    {
        void* ctxptr = new Wrapper([1, 2, 3]);
        auto context = cast(Wrapper*) ctxptr;
        writeln(context.x);
    }

How can I do that without the wrapper? `new int[]` isn't supported, even though that's exactly what I want.

On Wednesday, 10 January 2018 at 22:35:01 UTC, Luís Marques wrote:
> How can I do that without the wrapper? `new int[]` isn't supported, even though that's exactly what I want.

Just to be extra clear: I really do want a normal D slice, it can't be a fixed-length array.

Is there any problem with:

----
import std.stdio;

void main(string[] args)
{
    int[] x = [1, 2, 3];
    writeln(x);
}
----
https://run.dlang.io/is/CliWcz

On 01/10/2018 11:35 PM, Luís Marques wrote:
> Due to compatibility with some C code, I basically need to do this:
> 
>      struct Wrapper
>      {
>          int[] x;
>      }
> 
>      void main()
>      {
>          void* ctxptr = new Wrapper([1, 2, 3]);
>          auto context = cast(Wrapper*) ctxptr;
>          writeln(context.x);
>      }
> 
> How can I do that without the wrapper? `new int[]` isn't supported, even though that's exactly what I want.

If I understand correctly, the goal is to have the `int[]` itself on the GC heap. You can make an `int[][]` with one element, and then take the address of that element:

----
void main()
{
    int[]* x = &[[1, 2, 3]][0];
    int[]* x2 = [[1, 2, 3]].ptr; /* same */
}
----

On Wednesday, 10 January 2018 at 22:46:30 UTC, ag0aep6g wrote:
> If I understand correctly, the goal is to have the `int[]` itself on the GC heap.

General word of warning: if you pass it to C and the C function holds on to that pointer for any reason beyond its immediate execution, you could be looking at a problem because the D GC can't see C function memory and may free it after the function returns.

On Wednesday, 10 January 2018 at 22:46:30 UTC, ag0aep6g wrote:
> If I understand correctly, the goal is to have the `int[]` itself on the GC heap.

The code
----
void main(string[] args) @nogc
{
    int[] x = [1, 2, 3];
}
----

won't compile, because "array literal in @nogc function 'D main' may cause GC allocation". But "may" isn't the same as "will". What determines it? That's a kind of goofy error message now that I think about it.

On 01/10/2018 02:46 PM, ag0aep6g wrote:
> On 01/10/2018 11:35 PM, Luís Marques wrote:
>> Due to compatibility with some C code, I basically need to do this:
>>
>>      struct Wrapper
>>      {
>>          int[] x;
>>      }
>>
>>      void main()
>>      {
>>          void* ctxptr = new Wrapper([1, 2, 3]);
>>          auto context = cast(Wrapper*) ctxptr;
>>          writeln(context.x);
>>      }
>>
>> How can I do that without the wrapper? `new int[]` isn't supported, even though that's exactly what I want.
> 
> If I understand correctly, the goal is to have the `int[]` itself on the GC heap. You can make an `int[][]` with one element, and then take the address of that element:
> 
> ----
> void main()
> {
>      int[]* x = &[[1, 2, 3]][0];
>      int[]* x2 = [[1, 2, 3]].ptr; /* same */
> }
> ----

I was writing the same for a no-initial-value version:

void main() {
    void *v = cast(void*)((new int[][](1)).ptr);
    *(cast(int[]*)v) ~= 42;
}

I hope it's correct. :o)

Ali

On Wednesday, 10 January 2018 at 22:48:48 UTC, Adam D. Ruppe wrote:
> General word of warning: if you pass it to C and the C function holds on to that pointer for any reason beyond its immediate execution, you could be looking at a problem because the D GC can't see C function memory and may free it after the function returns.

Thanks! I don't think it applies to me, because the void* pointer is reachable from a root pointer on the D side.

On Wednesday, 10 January 2018 at 22:46:30 UTC, ag0aep6g wrote:
> If I understand correctly, the goal is to have the `int[]` itself on the GC heap.

That's correct.

> You can make an `int[][]` with one element, and then take the address of that element:
>
> void main()
> {
>     int[]* x = &[[1, 2, 3]][0];
>     int[]* x2 = [[1, 2, 3]].ptr; /* same */
> }

That's an interesting solution. I'm not sure which one I prefer, the wrapper or this one. Still... I feel like the language should just allow allocating an array itself on the GC heap :(

On Wednesday, January 10, 2018 22:50:22 Nathan S. via Digitalmars-d-learn wrote:
> On Wednesday, 10 January 2018 at 22:46:30 UTC, ag0aep6g wrote:
> > If I understand correctly, the goal is to have the `int[]` itself on the GC heap.
>
> The code
> ----
> void main(string[] args) @nogc
> {
>      int[] x = [1, 2, 3];
> }
> ----
>
> won't compile, because "array literal in @nogc function 'D main' may cause GC allocation". But "may" isn't the same as "will". What determines it? That's a kind of goofy error message now that I think about it.

If there are cases where it doesn't allocate, it probably depends on compiler optimizations. If it's able to determine that x doesn't escape the function, it might allocate it on the stack. I don't know. But @nogc is about guaranteeing that it _won't_ allocate using the GC, so "may" is enough to make it illegal for @nogc. It's also possible that this particular case will always allocate, but the error message is also used in other code where it's not guaranteed to allocate. Recently, in a discussion on improving error messages Walter did mention that there are cases in the compiler where the same piece of code generates errors for a variety of cases and that it would probably be better to make some of those less generic so that the error messages can be more specific.

- Jonathan M Davis