I'm not sure about proper understanding of RAII idiom, but should objects in array be automatically constructed during array initialization?

Example.

class ClassPoint {
    int x,y;
}

struct StructPoint {
    int x,y;
}

ClassPoint[8] arr; //static array of null references;
StructPoint[8] arr2;

arr[0].x=1 //error, there is no object
arr2[0].x=1 //OK.

Here I have two questions:

1) Can you have automatically constructed objects with default class constructor?
2) Can you setup memory attributes for static array using core.memory functions, say, to force GC not to scan this portion of memory during collection?

On Saturday, 12 January 2013 at 19:07:38 UTC, Andrey wrote:
> I'm not sure about proper understanding of RAII idiom, but should objects in array be automatically constructed during array initialization?

Members of static arrays are initialized to their default values.

> Example.
>
> class ClassPoint {
>     int x,y;
> }

This is initialized to null.

> struct StructPoint {
>     int x,y;
> }

This is initialized to StructPoint(0,0).

> ClassPoint[8] arr; //static array of null references;
> StructPoint[8] arr2;
>
> arr[0].x=1 //error, there is no object
> arr2[0].x=1 //OK.
>
> Here I have two questions:
>
> 1) Can you have automatically constructed objects with default class constructor?

No. It is possible to create a wrapper struct type with "alias this" to ClassPoint[8], which defaults to preallocated objects, but as a drawback each instance of such type would default to same class references and this makes the hack mostly unusable.

> 2) Can you setup memory attributes for static array using core.memory functions, say, to force GC not to scan this portion of memory during collection?

I do not understand what you mean here.

>> 2) Can you setup memory attributes for static array using core.memory functions, say, to force GC not to scan this portion of memory during collection?
>
> I do not understand what you mean here.

I mean static uint setAttr(in void* p, uint a) from core.memory and enum BlkAttr.NO_SCAN;

Can I use here cast(void*)arr.ptr and what effect it will cause on array of class objects?

I don't know the answers to those difficult questions. So I offer only partial tentative comments.

Maxim Fomin answering Andrey:

>> ClassPoint[8] arr; //static array of null references;

I prefer to call them fixed sized arrays, because the "static" word is too much overloaded in D.


>> StructPoint[8] arr2;
>>
>> arr[0].x=1 //error, there is no object
>> arr2[0].x=1 //OK.
>>
>> Here I have two questions:
>>
>> 1) Can you have automatically constructed objects with default class constructor?
>
> No. It is possible to create a wrapper struct type with "alias this" to ClassPoint[8], which defaults to preallocated objects, but as a drawback each instance of such type would default to same class references and this makes the hack mostly unusable.

If ClassPoint has just a default constructor and the original poster wants to allocate those class instances in place, then maybe it's possible to invent something like this, that creates initialized class instances, but I think it's not very useful:

Emplace!(ClassPoint)[8] arr;


>> 2) Can you setup memory attributes for static array using core.memory functions, say, to force GC not to scan this portion of memory during collection?
>
> I do not understand what you mean here.

I think currently you can't tell the GC to ignore part of the stack. Fixed sized arrays are sometimes on the stack. So maybe it's not possible.

Bye,
bearophile

Andrey:

> Can I use here cast(void*)arr.ptr and what effect it will cause on array of class objects?

If that array is allocated on the heap them mabye the GC will ignore those class instances.

Bye,
bearophile

> If that array is allocated on the heap them mabye the GC will ignore those class instances.

I think GC scans stack for pointers. At least, official manual says this:

The garbage collector looks for roots in:
1) the static data segment
2) the stacks and register contents of each thread
3) the TLS (thread-local storage) areas of each thread
4) any roots added by core.memory.GC.addRoot() or core.memory.GC.addRange()

If the only pointer to an object is held outside of these areas, then the collector will miss it and free the memory.

Andrey:

> I think GC scans stack for pointers.

Right. And I think you can't stop the GC from scanning the stack.


> The garbage collector looks for roots in:
> ...

What I meant to say is that if you put the fixed sized array on the heap then maybe you can mark it as noscan.

Maybe if you tell us more generally what you are trying to do, we can answer something useful :-)

Bye,
bearophile

On Saturday, 12 January 2013 at 20:18:59 UTC, bearophile wrote:
> Maxim Fomin answering Andrey:
>
>>> ClassPoint[8] arr; //static array of null references;
>
> I prefer to call them fixed sized arrays, because the "static" word is too much overloaded in D.

I see, but these names are interchangeable. Dlang.org uses "static" (as opposed to dynamic) and tdpl tends to use fixed-size name.

> Bye,
> bearophile

> Maybe if you tell us more generally what you are trying to do, we can answer something useful :-)

:-) I'm trying to explore the possibilities of memory management in D for
fine tuning of real long time running applications. Such technique as object pools, which are more friendly to CPU cache. I know that you can use std.conv.emplace stuff, but I'm trying to stay within GC.

I use unrolled linked lists, which consist of connected fixed array chunks, allocated on the GC heap.

Anyway, thanks everyone for answers.

Maxim Fomin:

> I see, but these names are interchangeable. Dlang.org uses "static" (as opposed to dynamic) and tdpl tends to use fixed-size name.

If you call a1 static array, then what name do you give to a2? A static static array?

void main() {
    int[5] a1;
    static int[5] a2;
    __gshared int[5] a3;
}

Bye,
bearophile