On Wed, May 04, 2022 at 10:04:53PM +, forkit via Digitalmars-d-learn wrote:
> On Wednesday, 4 May 2022 at 21:55:18 UTC, H. S. Teoh wrote:
> > On Wed, May 04, 2022 at 09:46:50PM +, forkit via Digitalmars-d-learn
> > wrote: [...]
[...]
> > > To deny a programmer the option to release the memo
On Wednesday, 4 May 2022 at 21:55:18 UTC, H. S. Teoh wrote:
On Wed, May 04, 2022 at 09:46:50PM +, forkit via
Digitalmars-d-learn wrote: [...]
That languages with GC typically give the programmer some
control over the GC, is evidence that programmers do care
(otherwise such features would no
On Wednesday, 4 May 2022 at 15:04:13 UTC, cc wrote:
The MemUtils package offers a `ScopedPool` utility that seems
interesting. It isn't well documented however so I have no
idea if it actually works like I expect. I presume this would
work something akin to a VM memory snapshot/rollback for t
On Wed, May 04, 2022 at 09:46:50PM +, forkit via Digitalmars-d-learn wrote:
[...]
> That languages with GC typically give the programmer some control over
> the GC, is evidence that programmers do care (otherwise such features
> would not be needed).
>
> To deny a programmer the option to rele
On Wednesday, 4 May 2022 at 12:57:26 UTC, Ali Çehreli wrote:
On 5/3/22 22:37, forkit wrote:
> In any case, I disagree that caring about when memory gets
deallocted
> means you shouldn't be using GC. (or did I get that one wrong
too??)
At least I don't agree with you there. :) Yes, one should no
The MemUtils package offers a `ScopedPool` utility that seems
interesting. It isn't well documented however so I have no idea
if it actually works like I expect. I presume this would work
something akin to a VM memory snapshot/rollback for the GC? It
would be pretty handy for some scenarios,
On 5/3/22 22:37, forkit wrote:
> In any case, I disagree that caring about when memory gets deallocted
> means you shouldn't be using GC. (or did I get that one wrong too??)
At least I don't agree with you there. :) Yes, one should not care about
how memory gets freed if one did not care how th
On Wednesday, 4 May 2022 at 08:23:33 UTC, Mike Parker wrote:
On Wednesday, 4 May 2022 at 05:37:49 UTC, forkit wrote:
That's not at all what I said. You don't have to care about
*when* memory is deallocated, meaning you don't have to
manage it yourself.
In any case, I disagree that caring abo
On Wednesday, 4 May 2022 at 05:37:49 UTC, forkit wrote:
inscope int[] i = new int[1];
You often see the "here's an array of ints that exists only in
one scope to do one thing, should we leave it floating in memory
or destroy it immediately?" as examples for these GC discussions.
Not
On Wednesday, 4 May 2022 at 05:37:49 UTC, forkit wrote:
That's not at all what I said. You don't have to care about
*when* memory is deallocated, meaning you don't have to manage
it yourself.
In any case, I disagree that caring about when memory gets
deallocted means you shouldn't be using G
On Wednesday, 4 May 2022 at 05:13:04 UTC, Mike Parker wrote:
On Wednesday, 4 May 2022 at 04:52:05 UTC, forkit wrote:
It is certainly *not* about you not having to care anymore
(about memory management).
That's not at all what I said. You don't have to care about
*when* memory is dealloca
On Wednesday, 4 May 2022 at 04:52:05 UTC, forkit wrote:
It is certainly *not* about you not having to care anymore
(about memory management).
That's not at all what I said. You don't have to care about
*when* memory is deallocated, meaning you don't have to manage it
yourself.
On Wednesday, 4 May 2022 at 02:42:44 UTC, Mike Parker wrote:
On Tuesday, 3 May 2022 at 14:57:46 UTC, Alain De Vos wrote:
Note, It's not i'm against GC. But my preference is to use
builtin types and libraries if possible,
But at the same time be able to be sure memory is given free
when a variab
On Tuesday, 3 May 2022 at 14:57:46 UTC, Alain De Vos wrote:
Note, It's not i'm against GC. But my preference is to use
builtin types and libraries if possible,
But at the same time be able to be sure memory is given free
when a variable is going out of scope.
It seems not easy to combine the two
On Tuesday, 3 May 2022 at 12:59:31 UTC, Alain De Vos wrote:
Error: array literal in @nogc function test.myfun may cause a
GC allocation
@nogc void myfun(){
scope int[] i=[1,2,3];
}//myfun
May is a fuzzy word...
For this particular piece of code, you can use a static array to
guarant
On 5/3/22 07:57, Alain De Vos wrote:
> But at the same time be able to be sure memory is given free when a
> variable is going out of scope.
Let's expand on that please. What exactly is the worry there? Are you
concerned that the program will have memory leaks, and eventually got
killed by the
On Tue, May 03, 2022 at 02:57:46PM +, Alain De Vos via Digitalmars-d-learn
wrote:
> Note, It's not i'm against GC. But my preference is to use builtin
> types and libraries if possible,
> But at the same time be able to be sure memory is given free when a
> variable is going out of scope.
> It
Note, It's not i'm against GC. But my preference is to use
builtin types and libraries if possible,
But at the same time be able to be sure memory is given free when
a variable is going out of scope.
It seems not easy to combine the two with a GC which does his
best effort but as he likes or not
On Tuesday, 3 May 2022 at 12:59:31 UTC, Alain De Vos wrote:
Error: array literal in @nogc function test.myfun may cause a
GC allocation
@nogc void myfun(){
scope int[] i=[1,2,3];
}//myfun
May is a fuzzy word...
It means if the compiler is free to allocate on the stack if
possible. I
Error: array literal in @nogc function test.myfun may cause a GC
allocation
@nogc void myfun(){
scope int[] i=[1,2,3];
}//myfun
May is a fuzzy word...
On Saturday, 30 April 2022 at 11:37:32 UTC, Tejas wrote:
Hell, just using `scope int[] i` should be enough to trigger
deterministic destruction, no? `typecons`'s `Scoped!` template
can be used if 100% guarantee is needed _and_ the memory has to
be stack allocated
Didn't think of that. To be f
On Saturday, 30 April 2022 at 09:25:18 UTC, Dukc wrote:
On Sunday, 24 April 2022 at 21:00:50 UTC, Alain De Vod wrote:
[...]
A few picks.
1: You do not need to import `destroy`. Everything in `object`
is automatically imported.
[...]
Hell, just using `scope int[] i` should be enough to tr
On Sunday, 24 April 2022 at 21:00:50 UTC, Alain De Vod wrote:
Is this a correct program to explicit call destroy & free ?
```
void main(){
int[] i=new int[1];
import object: destroy;
destroy(i);
import core.memory: GC;
GC.free(GC.addrOf(cast(void *)(i.ptr)));
}
```
A fe
On Monday, 25 April 2022 at 14:25:17 UTC, H. S. Teoh wrote:
On Mon, Apr 25, 2022 at 01:28:01PM +, Alain De Vos via
Digitalmars-d-learn wrote:
Could thc or hboehm provide solutions ?
In general, GC (of any kind) does not (and cannot) guarantee
the order
objects will be collected in. So in
On 4/25/22 16:02, frame wrote:
> On Monday, 25 April 2022 at 02:07:50 UTC, Ali Çehreli wrote:
>> > import core.memory: GC;
>> GC.free(GC.addrOf(cast(void *)(i.ptr)));
>> That is wrong because you did not allocate that address yourself.
>
> Hmm? The GC did allocate here(?)
Yes. I still d
On Monday, 25 April 2022 at 02:07:50 UTC, Ali Çehreli wrote:
> import core.memory: GC;
GC.free(GC.addrOf(cast(void *)(i.ptr)));
That is wrong because you did not allocate that address
yourself.
Hmm? The GC did allocate here(?)
On 4/24/22 17:26, Salih Dincer wrote:
>MEM.free(i.
On Mon, Apr 25, 2022 at 01:28:01PM +, Alain De Vos via Digitalmars-d-learn
wrote:
> Could thc or hboehm provide solutions ?
In general, GC (of any kind) does not (and cannot) guarantee the order
objects will be collected in. So in the dtor, you cannot assume that any
objects you depend on sti
Could thc or hboehm provide solutions ?
GC-allocated objects are run (when they are run). If you need
deterministic destruction e.g. for resource management, do not
use GC.
Descend destroy and free functions should return something.
"destroy" should return if the destructor was called successfully.
"free" should return the exact numb
On Monday, 25 April 2022 at 10:13:43 UTC, Alain De Vos wrote:
Ali, thanks for the answer but i rephrase my question.
How to destroy,free , for garbage-collection-cycle in the
destructor of this code :
// But How to force destroy and free , GC-cycle for heap object
i ?
Short answer: use `des
Note, heap object i is not an instance of the class C
On Monday, 25 April 2022 at 10:13:43 UTC, Alain De Vos wrote:
destructor of this code :
```d
~this(){
writeln("Free heap");
import object: destroy;
import core.memory: GC;
i=null;
// But How to force destroy and free , GC-cycle for heap
object i ?
};
```
If
Ali, thanks for the answer but i rephrase my question.
How to destroy,free , for garbage-collection-cycle in the
destructor of this code :
```
import std.stdio: writeln;
class C{
int[] i=null;
this(){
writeln("Allocate heap");
i=new int[1];
On 4/24/22 17:26, Salih Dincer wrote:
> first destroy() then free()...
Makes sense only if we allocated the memory.
> import object: doDestroy = destroy;
I like adding 'do' to verbs that can be confused with nouns. For
example, because 'copy' is both a noun and a verb, I think it helps when
On 4/24/22 14:00, Alain De Vod wrote:
> Is this a correct program to explicit call destroy & free ?
destroy() is called with the object that you want its destructor to be
executed on. This is very rare in D because when the destructor has to
be called, one relies on the lifetime of a struct obj
On Sunday, 24 April 2022 at 21:00:50 UTC, Alain De Vod wrote:
Is this a correct program to explicit call destroy & free ?
```
void main(){
int[] i=new int[1];
import object: destroy;
destroy(i);
import core.memory: GC;
GC.free(GC.addrOf(cast(void *)(i.ptr)));
}
```
Yes,
Is this a correct program to explicit call destroy & free ?
```
void main(){
int[] i=new int[1];
import object: destroy;
destroy(i);
import core.memory: GC;
GC.free(GC.addrOf(cast(void *)(i.ptr)));
}
```
37 matches
Mail list logo
