View mode: basic / threaded / horizontal-split · Log in · Help
May 15, 2012
allocate array with new
Is there any other difference if I allocate an array with "new", 
except that it is initialized?
And must i delete it by myself, or take the GC care about that?
The documentary leaves me hanging there, unfortunately, and gives 
me no 100% answer.

Once before, thanks for the reply.
May 15, 2012
Re: allocate array with new
Difference with what?
new is a safe feature: it allocates in the GC heap
May 15, 2012
Re: allocate array with new
On Tuesday, 15 May 2012 at 09:23:51 UTC, Kagamin wrote:
> Difference with what?
> new is a safe feature: it allocates in the GC heap

That's what i mean. So i have to delete it yourself with "delete 
arr;", or not?
May 15, 2012
Re: allocate array with new
On Tuesday, May 15, 2012 11:26:49 Namespace wrote:
> On Tuesday, 15 May 2012 at 09:23:51 UTC, Kagamin wrote:
> > Difference with what?
> > new is a safe feature: it allocates in the GC heap
> 
> That's what i mean. So i have to delete it yourself with "delete
> arr;", or not?

No. _Never_ use delete. It's going to be deprecated. The GC worries about 
freeing memory allocated on the GC heap, and new always allocates on the GC 
heap. If you don't want to allocate on the GC heap, then use malloc and free, 
in which case you _do_ need worry about freeing the memory.

If you need to force destruction before the GC collects an object, you can 
call clear on that object to have its destructor called and its vtbl zeroed 
out, but it's memory still isn't freed. That's the GC's job.

If you really have to, you can use core.memory to manipulate the GC heap 
(including calling GC.free), but you really shouldn't be messing with any of 
that unless you really need to and you know what you're doing.

- Jonathan M Davis
May 15, 2012
Re: allocate array with new
On Tuesday, 15 May 2012 at 09:44:08 UTC, Jonathan M Davis wrote:
> On Tuesday, May 15, 2012 11:26:49 Namespace wrote:
>> On Tuesday, 15 May 2012 at 09:23:51 UTC, Kagamin wrote:
>> > Difference with what?
>> > new is a safe feature: it allocates in the GC heap
>> 
>> That's what i mean. So i have to delete it yourself with 
>> "delete
>> arr;", or not?
>
> No. _Never_ use delete. It's going to be deprecated. The GC 
> worries about
> freeing memory allocated on the GC heap, and new always 
> allocates on the GC
> heap. If you don't want to allocate on the GC heap, then use 
> malloc and free,
> in which case you _do_ need worry about freeing the memory.
>
> If you need to force destruction before the GC collects an 
> object, you can
> call clear on that object to have its destructor called and its 
> vtbl zeroed
> out, but it's memory still isn't freed. That's the GC's job.
>
> If you really have to, you can use core.memory to manipulate 
> the GC heap
> (including calling GC.free), but you really shouldn't be 
> messing with any of
> that unless you really need to and you know what you're doing.
>
> - Jonathan M Davis

Understood. Never use delete. Fine. :)
May 15, 2012
Re: allocate array with new
On Tuesday, 15 May 2012 at 09:44:08 UTC, Jonathan M Davis wrote:
> On Tuesday, May 15, 2012 11:26:49 Namespace wrote:
>> On Tuesday, 15 May 2012 at 09:23:51 UTC, Kagamin wrote:
>> > Difference with what?
>> > new is a safe feature: it allocates in the GC heap
>> 
>> That's what i mean. So i have to delete it yourself with 
>> "delete
>> arr;", or not?
>
> No. _Never_ use delete. It's going to be deprecated. The GC 
> worries about
> freeing memory allocated on the GC heap, and new always 
> allocates on the GC
> heap. If you don't want to allocate on the GC heap, then use 
> malloc and free,
> in which case you _do_ need worry about freeing the memory.
>
> If you need to force destruction before the GC collects an 
> object, you can
> call clear on that object to have its destructor called and its 
> vtbl zeroed
> out, but it's memory still isn't freed. That's the GC's job.
>
> If you really have to, you can use core.memory to manipulate 
> the GC heap
> (including calling GC.free), but you really shouldn't be 
> messing with any of
> that unless you really need to and you know what you're doing.
>
> - Jonathan M Davis

Hi,
does this hold for structs too?

struct H
{
this(int a){writeln("ctor");}
~this(){writeln("dtor");}
};

...

H* h = new H(5);
clear(h);
...

output:

ctor

seems like destructor is not called.

if I change declaration of H to class H. output is following:

ctor
dtor

I tried to create object according to RAII idiom and in case of 
struct H my file handle remained open  and I was still able to 
write to file...

Ondrej
May 15, 2012
Re: allocate array with new
On 15.05.2012 16:27, Ondrej Pokorny wrote:
> On Tuesday, 15 May 2012 at 09:44:08 UTC, Jonathan M Davis wrote:
>> On Tuesday, May 15, 2012 11:26:49 Namespace wrote:
>>> On Tuesday, 15 May 2012 at 09:23:51 UTC, Kagamin wrote:
>>> > Difference with what?
>>> > new is a safe feature: it allocates in the GC heap
>>>
>>> That's what i mean. So i have to delete it yourself with "delete
>>> arr;", or not?
>>
>> No. _Never_ use delete. It's going to be deprecated. The GC worries about
>> freeing memory allocated on the GC heap, and new always allocates on
>> the GC
>> heap. If you don't want to allocate on the GC heap, then use malloc
>> and free,
>> in which case you _do_ need worry about freeing the memory.
>>
>> If you need to force destruction before the GC collects an object, you
>> can
>> call clear on that object to have its destructor called and its vtbl
>> zeroed
>> out, but it's memory still isn't freed. That's the GC's job.
>>
>> If you really have to, you can use core.memory to manipulate the GC heap
>> (including calling GC.free), but you really shouldn't be messing with
>> any of
>> that unless you really need to and you know what you're doing.
>>
>> - Jonathan M Davis
>
> Hi,
> does this hold for structs too?
>
> struct H
> {
> this(int a){writeln("ctor");}
> ~this(){writeln("dtor");}
> };
>
> ...
>
> H* h = new H(5);
> clear(h);
> ...
>
> output:
>
> ctor
>
> seems like destructor is not called.
>
> if I change declaration of H to class H. output is following:
>
> ctor
> dtor
>
> I tried to create object according to RAII idiom and in case of struct H
> my file handle remained open and I was still able to write to file...
>
> Ondrej
>
I thought in C++ RAII is about (i.e. even in C++ no heap allocation):
H h = H(5);

Same works in D. A call to clear  in you code above doesn't call 
destructor, it only zeros out pointer.
If you absolutely need pointers & heap and yet manual memory managment use:
clear(*h);


Explanation:
clear(x) calls x.__dtor if x is struct or class, then assigns
x = T.init;

A better way might be to just check if x.__dtor is callbale (thus 
pointer to sstruct will also work).

-- 
Dmitry Olshansky
May 15, 2012
Re: allocate array with new
On 15/05/12 11:43, Jonathan M Davis wrote:
> No. _Never_ use delete. It's going to be deprecated.

What if you turn the GC off?
May 15, 2012
Re: allocate array with new
On Tuesday, 15 May 2012 at 12:36:30 UTC, Dmitry Olshansky wrote:
> On 15.05.2012 16:27, Ondrej Pokorny wrote:
>> On Tuesday, 15 May 2012 at 09:44:08 UTC, Jonathan M Davis 
>> wrote:
>>> On Tuesday, May 15, 2012 11:26:49 Namespace wrote:
>>>> On Tuesday, 15 May 2012 at 09:23:51 UTC, Kagamin wrote:
>>>> > Difference with what?
>>>> > new is a safe feature: it allocates in the GC heap
>>>>
>>>> That's what i mean. So i have to delete it yourself with 
>>>> "delete
>>>> arr;", or not?
>>>
>>> No. _Never_ use delete. It's going to be deprecated. The GC 
>>> worries about
>>> freeing memory allocated on the GC heap, and new always 
>>> allocates on
>>> the GC
>>> heap. If you don't want to allocate on the GC heap, then use 
>>> malloc
>>> and free,
>>> in which case you _do_ need worry about freeing the memory.
>>>
>>> If you need to force destruction before the GC collects an 
>>> object, you
>>> can
>>> call clear on that object to have its destructor called and 
>>> its vtbl
>>> zeroed
>>> out, but it's memory still isn't freed. That's the GC's job.
>>>
>>> If you really have to, you can use core.memory to manipulate 
>>> the GC heap
>>> (including calling GC.free), but you really shouldn't be 
>>> messing with
>>> any of
>>> that unless you really need to and you know what you're doing.
>>>
>>> - Jonathan M Davis
>>
>> Hi,
>> does this hold for structs too?
>>
>> struct H
>> {
>> this(int a){writeln("ctor");}
>> ~this(){writeln("dtor");}
>> };
>>
>> ...
>>
>> H* h = new H(5);
>> clear(h);
>> ...
>>
>> output:
>>
>> ctor
>>
>> seems like destructor is not called.
>>
>> if I change declaration of H to class H. output is following:
>>
>> ctor
>> dtor
>>
>> I tried to create object according to RAII idiom and in case 
>> of struct H
>> my file handle remained open and I was still able to write to 
>> file...
>>
>> Ondrej
>>
> I thought in C++ RAII is about (i.e. even in C++ no heap 
> allocation):
> H h = H(5);
>
> Same works in D. A call to clear  in you code above doesn't 
> call destructor, it only zeros out pointer.
> If you absolutely need pointers & heap and yet manual memory 
> managment use:
> clear(*h);
>
>
> Explanation:
> clear(x) calls x.__dtor if x is struct or class, then assigns
> x = T.init;
>
> A better way might be to just check if x.__dtor is callbale 
> (thus pointer to sstruct will also work).

I don't need this stuff I am playing with language and wonder
why. Originally I had there auto h = H(5); and after changing H
to struct I did not realized why that happened.

Thanks a lot for explanation, now it makes perfect sense, but I
have still little bit unpleasant felling about it because of
behavior of ref to classes vs pointers to structs with clear.
Both are dynamically allocated data, so I was expecting same
response from clear(x).

Ondrej
May 15, 2012
Re: allocate array with new
On 15.05.2012 17:12, Ondrej Pokorny wrote:
> On Tuesday, 15 May 2012 at 12:36:30 UTC, Dmitry Olshansky wrote:
>> On 15.05.2012 16:27, Ondrej Pokorny wrote:
>>> On Tuesday, 15 May 2012 at 09:44:08 UTC, Jonathan M Davis wrote:
>>>> On Tuesday, May 15, 2012 11:26:49 Namespace wrote:
>>>>> On Tuesday, 15 May 2012 at 09:23:51 UTC, Kagamin wrote:
>>>>> > Difference with what?
>>>>> > new is a safe feature: it allocates in the GC heap
>>>>>
>>>>> That's what i mean. So i have to delete it yourself with "delete
>>>>> arr;", or not?
>>>>
>>>> No. _Never_ use delete. It's going to be deprecated. The GC worries
>>>> about
>>>> freeing memory allocated on the GC heap, and new always allocates on
>>>> the GC
>>>> heap. If you don't want to allocate on the GC heap, then use malloc
>>>> and free,
>>>> in which case you _do_ need worry about freeing the memory.
>>>>
>>>> If you need to force destruction before the GC collects an object, you
>>>> can
>>>> call clear on that object to have its destructor called and its vtbl
>>>> zeroed
>>>> out, but it's memory still isn't freed. That's the GC's job.
>>>>
>>>> If you really have to, you can use core.memory to manipulate the GC
>>>> heap
>>>> (including calling GC.free), but you really shouldn't be messing with
>>>> any of
>>>> that unless you really need to and you know what you're doing.
>>>>
>>>> - Jonathan M Davis
>>>
>>> Hi,
>>> does this hold for structs too?
>>>
>>> struct H
>>> {
>>> this(int a){writeln("ctor");}
>>> ~this(){writeln("dtor");}
>>> };
>>>
>>> ...
>>>
>>> H* h = new H(5);
>>> clear(h);
>>> ...
>>>
>>> output:
>>>
>>> ctor
>>>
>>> seems like destructor is not called.
>>>
>>> if I change declaration of H to class H. output is following:
>>>
>>> ctor
>>> dtor
>>>
>>> I tried to create object according to RAII idiom and in case of struct H
>>> my file handle remained open and I was still able to write to file...
>>>
>>> Ondrej
>>>
>> I thought in C++ RAII is about (i.e. even in C++ no heap allocation):
>> H h = H(5);
>>
>> Same works in D. A call to clear in you code above doesn't call
>> destructor, it only zeros out pointer.
>> If you absolutely need pointers & heap and yet manual memory managment
>> use:
>> clear(*h);
>>
>>
>> Explanation:
>> clear(x) calls x.__dtor if x is struct or class, then assigns
>> x = T.init;
>>
>> A better way might be to just check if x.__dtor is callbale (thus
>> pointer to sstruct will also work).
>
> I don't need this stuff I am playing with language and wonder
> why. Originally I had there auto h = H(5); and after changing H
> to struct I did not realized why that happened.
>
> Thanks a lot for explanation, now it makes perfect sense, but I
> have still little bit unpleasant felling about it because of
> behavior of ref to classes vs pointers to structs with clear.
> Both are dynamically allocated data, so I was expecting same
> response from clear(x).
>

Like I said it's easily fixable at a cost of breaking some code that 
relies on this clear(ptr) zeroing out pointer. I think that it's wrong 
code anyway. So I I'll wrap up a pull request to do just that.


-- 
Dmitry Olshansky
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home