On 9/13/22 04:07, test123 wrote:
> On Tuesday, 13 September 2022 at 10:59:36 UTC, Dennis wrote:

>> Side node, you can use `immutable` instead of `__gshared const`, it
>> amounts to the same for global variables.
>
> because __enums_layout.ptr need to be part of other object, and this
> const ptr cloud be included in multi objects.

There may be valid reasons not to use 'immutable' but you can still do what you describe. There is an 'immutable' array below and its .ptr is being stored as 'const' inside objects of another struct.

struct S {
    int i;
    string s;
    int[3] arr;
}

immutable S[] imm;

shared static this() {
    // Initializing immutable at program initialization time:
    imm ~= S(42, "hello", [1,2,3]);
    imm ~= S(7, "world", [4,5,6]);
}

struct Other {
    const S * ptr;
}

void main() {
    auto o = Other(imm.ptr);
}

That works because 'const' can point to 'immutable' (and mutable and const).

Ali

On Tuesday, 13 September 2022 at 23:34:33 UTC, Ali Çehreli wrote:
> On 9/13/22 04:07, test123 wrote:
> > On Tuesday, 13 September 2022 at 10:59:36 UTC, Dennis wrote:
>
> >> Side node, you can use `immutable` instead of `__gshared
> const`, it
> >> amounts to the same for global variables.
> >
> > because __enums_layout.ptr need to be part of other object,
> and this
> > const ptr cloud be included in multi objects.
>
> There may be valid reasons not to use 'immutable' but you can still do what you describe. There is an 'immutable' array below and its .ptr is being stored as 'const' inside objects of another struct.
>
> struct S {
>     int i;
>     string s;
>     int[3] arr;
> }
>
> immutable S[] imm;
>
> shared static this() {
>     // Initializing immutable at program initialization time:
>     imm ~= S(42, "hello", [1,2,3]);
>     imm ~= S(7, "world", [4,5,6]);
> }
>
> struct Other {
>     const S * ptr;
> }
>
> void main() {
>     auto o = Other(imm.ptr);
> }
>
> That works because 'const' can point to 'immutable' (and mutable and const).
>
> Ali

Thanks for the tips.

This is for a protobuf module and the `int[3] arr;` is variable, (diff size struct cloud in same group), and each struct is reused in multi part. (and the total number can be big depend on GRPC model)

with `shared static this` the size is increased, and there is a lot depends relation need resolve during the protobuf init time. (the best solution is provide __gshared const relation map so no runtime cost, the C code way)


What I can see, the best solution to fix this is allow take address of member `__gshared const struct` like this:

```d
struct Header {
      int a;
      int b;
}
struct Message {
     Header header;
     uint[a] arr;
}
__gshared const Message type1 = {{1,2}, [3,4]};
__gshared const header_ptr = &type1.header;

// then you can reuse header_ptr in multi other __gshared const

```

D dont need change to support `C struct array`, and all relation is const safe in memory. (not able to write into this section of memory)



Current D support get `__gshared const struct` address, but not member of `__gshared const struct` address.  if you do so it will throw error:


```sh
expression &c(3u, 4u).a is not a constant
```


If you can `cast` the member address by the struct.offsetof, then this type error you get:

```sh
Error: reinterpreting cast from `const(validate_KnownRegex_enum_init_type)*` to `const(upb_MiniTable_Enum)*` is not supported in CTFE
```


I can not think of the reason why prevent get const member address of `__gshared const struct`.  and can not think of a workaround to bypass this problem.