On Fri, 01 Feb 2013 10:46:11 -0500, monarch_dodra
wrote:
On Friday, 1 February 2013 at 15:37:25 UTC, Steven Schveighoffer wrote:
This is a GC limitation, since structs do not contain a pointer to
their typeinfo like classes do, and there is no provision for storing a
pointer to the type
On 2013-02-01 16:37, Steven Schveighoffer wrote:
Actually, that's a different problem. File is a struct, and structs do NOT have
their destructor run by the GC. Only Objects do.
This is a GC limitation, since structs do not contain a pointer to their
typeinfo like classes do, and there is no p
On Jan 31, 2013, at 11:07 PM, "monarch_dodra" wrote:
> On Thursday, 31 January 2013 at 23:53:26 UTC, Steven Schveighoffer wrote:
>>
>> A destructor should ONLY be used to free up resources other than GC
>> allocated memory. Because of that, it's generally not used.
>>
>> It should be used a
On Friday, 1 February 2013 at 15:37:25 UTC, Steven Schveighoffer
wrote:
On Fri, 01 Feb 2013 02:07:00 -0500, monarch_dodra
wrote:
On Thursday, 31 January 2013 at 23:53:26 UTC, Steven
Schveighoffer wrote:
A destructor should ONLY be used to free up resources other
than GC allocated memory.
On Fri, 01 Feb 2013 02:07:00 -0500, monarch_dodra
wrote:
On Thursday, 31 January 2013 at 23:53:26 UTC, Steven Schveighoffer wrote:
A destructor should ONLY be used to free up resources other than GC
allocated memory. Because of that, it's generally not used.
It should be used almost as
On Thursday, 31 January 2013 at 23:53:26 UTC, Steven
Schveighoffer wrote:
A destructor should ONLY be used to free up resources other
than GC allocated memory. Because of that, it's generally not
used.
It should be used almost as a "last resort".
For example, a class that holds a file desc
On Thursday, 31 January 2013 at 23:53:26 UTC, Steven
Schveighoffer wrote:
On Thu, 31 Jan 2013 18:27:59 -0500, Jeremy DeHaan
wrote:
On Wednesday, 30 January 2013 at 10:29:26 UTC, monarch_dodra
wrote:
To add to that, you also have to keep in mind that when the
program terminates (even legally)
On Thu, 31 Jan 2013 18:27:59 -0500, Jeremy DeHaan
wrote:
On Wednesday, 30 January 2013 at 10:29:26 UTC, monarch_dodra wrote:
To add to that, you also have to keep in mind that when the program
terminates (even legally), instead of running a *full* collect cycle,
the program just leaves, a
On Wednesday, 30 January 2013 at 10:29:26 UTC, monarch_dodra
wrote:
To add to that, you also have to keep in mind that when the
program terminates (even legally), instead of running a *full*
collect cycle, the program just leaves, and lets the OS clear
any allocated memory. This is both faster,
GG.reserve can be handy for this. It tells the GC to pre allocate a block of
memory from the OS.
On Jan 31, 2013, at 7:12 AM, "Steven Schveighoffer" wrote:
> On Wed, 30 Jan 2013 03:15:14 -0500, Mike Parker wrote:
>
>> My understanding is that the current implementation only runs collections
On Wed, 30 Jan 2013 03:15:14 -0500, Mike Parker wrote:
My understanding is that the current implementation only runs
collections when memory is allocated. Meaning, when you allocate a new
object instance, or cause memory to be allocated via some built-in
operations (on arrays, for example)
On Wednesday, 30 January 2013 at 12:17:33 UTC, Maxim Fomin wrote:
English is not native for me. Sometimes non-natives
misunderstand the meaning of the words.
My apologies.
On Wednesday, 30 January 2013 at 12:08:07 UTC, monarch_dodra
wrote:
On Wednesday, 30 January 2013 at 11:57:01 UTC, Maxim Fomin
wrote:
On Wednesday, 30 January 2013 at 10:29:26 UTC, monarch_dodra
wrote:
On Wednesday, 30 January 2013 at 08:15:15 UTC, Mike Parker
wrote:
Destructors of members will
On Wednesday, 30 January 2013 at 11:57:01 UTC, Maxim Fomin wrote:
On Wednesday, 30 January 2013 at 10:29:26 UTC, monarch_dodra
wrote:
On Wednesday, 30 January 2013 at 08:15:15 UTC, Mike Parker
wrote:
Destructors of members will not be called when an object is
collected. Only that of the object
On Wednesday, 30 January 2013 at 10:29:26 UTC, monarch_dodra
wrote:
On Wednesday, 30 January 2013 at 08:15:15 UTC, Mike Parker
wrote:
Destructors of members will not be called when an object is
collected. Only that of the object itself. But, there's no
guarantee that any member references will
On Wednesday, 30 January 2013 at 08:15:15 UTC, Mike Parker wrote:
On Wednesday, 30 January 2013 at 06:00:44 UTC, Jeremy DeHaan
wrote:
From what I understand, when an object is recovered by the GC,
the destructor may or may not be called. Why is that? Is it for
That's not quite correct. Whe
The take-home point of all of this is that you shouldn't rely on
destructors for resource deallocation. You could do it in by
manually destructing objects when you are finished with them (via
the destroy() method), but then you have to be extra careful
about class members, ownership, order of d
On Wednesday, 30 January 2013 at 06:00:44 UTC, Jeremy DeHaan
wrote:
From what I understand, when an object is recovered by the GC,
the destructor may or may not be called. Why is that? Is it for
That's not quite correct. When the object is collected, its
destructor will be called. But you
I've been reading TDPL book and was also reading some posts on
these forums about the GC, but I wanted to clarify a few things
to make sure I am understanding correctly.
From what I understand, when an object is recovered by the GC,
the destructor may or may not be called. Why is that? Is it f
19 matches
Mail list logo
