On 5/21/15 8:40 AM, Kagamin wrote:
On Thursday, 21 May 2015 at 12:33:33 UTC, Steven Schveighoffer wrote:
At this moment, a thread-local-only heap pointer must deal with
multi-threading issues simply because destructors can run on another
thread, even though the reference is thread-local. The big
On Thursday, 21 May 2015 at 12:33:33 UTC, Steven Schveighoffer
wrote:
At this moment, a thread-local-only heap pointer must deal with
multi-threading issues simply because destructors can run on
another thread, even though the reference is thread-local. The
biggest example right now is referenc
On Thursday, 21 May 2015 at 12:33:33 UTC, Steven Schveighoffer
wrote:
At this moment, a thread-local-only heap pointer must deal with
multi-threading issues simply because destructors can run on
another thread, even though the reference is thread-local. The
biggest example right now is referenc
On 5/20/15 11:09 AM, Kagamin wrote:
On Wednesday, 20 May 2015 at 13:54:29 UTC, bitwise wrote:
Yes, but D claims to support manual memory management. It seems to get
second class treatment though.
It's WIP. There were thoughts to run finalizers on the thread where the
object was allocated (I do
On 5/19/15 7:03 PM, bitwise wrote:
On Tue, 19 May 2015 18:47:26 -0400, Steven Schveighoffer
wrote:
On 5/19/15 5:07 PM, bitwise wrote:
On Tue, 19 May 2015 15:36:21 -0400, rsw0x
wrote:
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
On Wednesday, 20 May 2015 at 13:54:29 UTC, bitwise wrote:
Yes, but D claims to support manual memory management. It seems
to get second class treatment though.
It's WIP. There were thoughts to run finalizers on the thread
where the object was allocated (I doubt it's a good idea,
though). Anyw
On Wednesday, 20 May 2015 at 08:01:46 UTC, Kagamin wrote:
On Tuesday, 19 May 2015 at 22:15:18 UTC, bitwise wrote:
Thanks for confirming, but given your apparent tendency toward
pinhole view points, it's unsurprising that you don't
understand what I'm asking.
And what you're asking. Just for t
On Tuesday, 19 May 2015 at 22:15:18 UTC, bitwise wrote:
Thanks for confirming, but given your apparent tendency toward
pinhole view points, it's unsurprising that you don't
understand what I'm asking.
And what you're asking. Just for the record: C++ memory
management techniques are not design
On Tue, 19 May 2015 19:16:14 -0400, Adam D. Ruppe
wrote:
On Tuesday, 19 May 2015 at 23:10:21 UTC, bitwise wrote:
which is why I am asking if there are any plans to implement
something like @nogc for entire modules or classes.
At the top:
@nogc:
Gotta do it inside the class too i th
On Tuesday, 19 May 2015 at 23:10:21 UTC, bitwise wrote:
which is why I am asking if there are any plans to
implement something like @nogc for entire modules or classes.
At the top:
@nogc:
Gotta do it inside the class too i think.
On Tue, 19 May 2015 19:03:02 -0400, bitwise wrote:
Maybe I worded that incorrectly, but my point is that when you're
running with the GC disabled, you should only use methods marked with
@nogc if you want to make sure your code doesn't leak right? that's a
lot of attributes O_O
Bit
.
On Tue, 19 May 2015 18:47:26 -0400, Steven Schveighoffer
wrote:
On 5/19/15 5:07 PM, bitwise wrote:
On Tue, 19 May 2015 15:36:21 -0400, rsw0x
wrote:
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
wrote:
On Tuesday, 19 May 201
On 5/19/15 5:07 PM, bitwise wrote:
On Tue, 19 May 2015 15:36:21 -0400, rsw0x wrote:
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this also true for D?
Yes. The
On Tue, 19 May 2015 17:52:36 -0400, rsw0x wrote:
On Tuesday, 19 May 2015 at 21:07:52 UTC, bitwise wrote:
Any idea what the plans are?. Does RefCounted become thread safe?
Correct me if I'm wrong though, but even if RefCounted itself was
thread-safe, RefCounted objects could still be placed
On Tuesday, 19 May 2015 at 21:07:52 UTC, bitwise wrote:
On Tue, 19 May 2015 15:36:21 -0400, rsw0x
wrote:
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this also
On 5/19/15 4:16 PM, Namespace wrote:
On Tuesday, 19 May 2015 at 20:02:07 UTC, rsw0x wrote:
"After dconf"
http://forum.dlang.org/thread/5554d763.1080...@dawg.eu#post-5554D763.1080308:40dawg.eu
I thought the new releases would come faster.
They should. This is an exception. Read the thread qu
On Tue, 19 May 2015 15:36:21 -0400, rsw0x wrote:
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this also true for D?
Yes. The GC considers all the unreferenced
On Tuesday, 19 May 2015 at 20:02:07 UTC, rsw0x wrote:
On Tuesday, 19 May 2015 at 19:45:38 UTC, Namespace wrote:
On Tuesday, 19 May 2015 at 19:36:23 UTC, rsw0x wrote:
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
wrote:
On Tuesday,
On Tuesday, 19 May 2015 at 19:45:38 UTC, Namespace wrote:
On Tuesday, 19 May 2015 at 19:36:23 UTC, rsw0x wrote:
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this a
On Tuesday, 19 May 2015 at 19:36:23 UTC, rsw0x wrote:
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this also true for D?
Yes. The GC considers all the unreference
On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this also true for D?
Yes. The GC considers all the unreferenced memory dead at the
same time and may clean up the cl
On Tue, 19 May 2015 14:55:55 -0400, Steven Schveighoffer
wrote:
On 5/19/15 2:37 PM, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this also true for D?
Yes. The GC considers all the unreferenced memory
On 5/19/15 2:37 PM, bitwise wrote:
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this also true for D?
Yes. The GC considers all the unreferenced memory dead at the same
time and may clean up the class and its members in
On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
wrote:
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this also true for D?
Yes. The GC considers all the unreferenced memory dead at the same time
and may clean up the class and its members in any order.
Ugh... I was really
On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
Is this also true for D?
Yes. The GC considers all the unreferenced memory dead at the
same time and may clean up the class and its members in any order.
In C#, it's possible that class members can actually be destroyed before
the containing object.
Example:
class Stuff
{
Class1 thing1;
Class2 thing2;
~Stuff() {
thing1.DoSomeFinalization(); // [1]
}
}
I forget what the exact behavior was, but basically, [1] is unsafe
26 matches
Mail list logo
