On Friday, 28 February 2014 at 14:47:31 UTC, Dicebot wrote:
On Friday, 28 February 2014 at 14:08:11 UTC, Namespace wrote:
No, currently it is not deprecated. It is suggested to be
deprecated. :P
And destroy doesn't finalize the data. :/ See:
http://forum.dlang.org/thread/bug-1225...@https.d.pur
On Friday, 28 February 2014 at 14:08:11 UTC, Namespace wrote:
No, currently it is not deprecated. It is suggested to be
deprecated. :P
And destroy doesn't finalize the data. :/ See:
http://forum.dlang.org/thread/bug-1225...@https.d.puremagic.com%2Fissues%2F
and
http://forum.dlang.org/thread/bu
On Friday, 28 February 2014 at 13:38:59 UTC, Dicebot wrote:
On Friday, 28 February 2014 at 13:32:33 UTC, Namespace wrote:
I will vote, too. It's somewhat strange: Since it works with
delete it should also work with the current GC, or? Someone
should figure out why and how delete works this way.
On Friday, 28 February 2014 at 13:16:40 UTC, Dicebot wrote:
On Friday, 28 February 2014 at 13:06:05 UTC, Namespace wrote:
What can still take a long time. It annoys me very much that
with arrays I can not rely on that the struct DTors are called.
Yep, this bug has immediately got my vote :) It
On Friday, 28 February 2014 at 13:32:33 UTC, Namespace wrote:
I will vote, too. It's somewhat strange: Since it works with
delete it should also work with the current GC, or? Someone
should figure out why and how delete works this way. :)
Well, delete is deprecated so it can do any kind of arc
On Friday, 28 February 2014 at 12:54:32 UTC, Dicebot wrote:
On Friday, 28 February 2014 at 12:36:48 UTC, Simon Bürger wrote:
If you are right that would mean that the current dmd/runtime
does not follow the spec. Curious. The current implementation
is not aware of strcut-destructors on the heap
On Friday, 28 February 2014 at 13:06:05 UTC, Namespace wrote:
What can still take a long time. It annoys me very much that
with arrays I can not rely on that the struct DTors are called.
Yep, this bug has immediately got my vote :) It does require
someone knowledgable of GC to fix in forseeabl
On Friday, 28 February 2014 at 12:36:48 UTC, Simon Bürger wrote:
If you are right that would mean that the current dmd/runtime
does not follow the spec. Curious. The current implementation
is not aware of strcut-destructors on the heap, i.e. the
GC.BlkAttr.FINALIZE flag is not set for structs (
On Friday, 28 February 2014 at 10:40:17 UTC, Dicebot wrote:
On Thursday, 27 February 2014 at 21:46:17 UTC, Simon Bürger
wrote:
Sadly, this is incorrect as well. Because if such an object is
collected by the gc, but the gc decides not to run the
destructor, the buffer will never be free'd.
I t
On Thursday, 27 February 2014 at 21:46:17 UTC, Simon Bürger wrote:
Sadly, this is incorrect as well. Because if such an object is
collected by the gc, but the gc decides not to run the
destructor, the buffer will never be free'd.
I think you misiterpret the spec. If object is collected,
destr
I asked something similar some days ago. Maybe this provides some
information tat is helpful to you:
http://forum.dlang.org/thread/mekdjoyejtfpafpcd...@forum.dlang.org
On Thu, 27 Feb 2014 16:46:15 -0500, Simon Bürger
wrote:
I know the suggested way in D is to not deallocate the buffer at all,
but rely on the gc to collect it eventually. But it still puzzles me
that it seems to be impossible to do. Anybody have an idea how I could
make it work?
Unfort
On Thursday, 27 February 2014 at 22:15:41 UTC, Steven
Schveighoffer wrote:
On Thu, 27 Feb 2014 16:46:15 -0500, Simon Bürger [...]
More and more, I think a thread-local flag of "I'm in the GC
collection cycle" would be hugely advantageous -- if it doesn't
already exist...
I don't think it does
On Thursday, 27 February 2014 at 22:04:50 UTC, Namespace wrote:
A struct is a value type. So it is passed by value and is
placed on the stack.
{
S s;
}
S DTor is called at the end of the scope. So you can rely on
RAII as long as you use structs.
On the stack yes. But not on the heap:
A struct is a value type. So it is passed by value and is placed
on the stack.
{
S s;
}
S DTor is called at the end of the scope. So you can rely on RAII
as long as you use structs.
I am trying to implement a structure with value semantics which
uses an internal buffer. The first approach looks like this:
struct S
{
byte[] buf;
this(int size) { buf = new byte[size]; }
this(this) { buf = buf.dup; }
~this(this) { delete buf; }
}
T
16 matches
Mail list logo
