On Tuesday, 29 October 2013 at 11:46:53 UTC, Rene Zwanenburg
wrote:
On Monday, 28 October 2013 at 19:30:12 UTC, Maxim Fomin wrote:
Here is my attempt:
import std.stdio;
struct S
{
int i;
this(int i) { writefln("ctor, %X", i); this.i = i; }
this(this) { writefln("postblit, %X, %X", &th
On 10/29/2013 11:11 AM, Maxim Fomin wrote:
> On Tuesday, 29 October 2013 at 17:57:01 UTC, Ali Çehreli wrote:
>> http://forum.dlang.org/post/l4osr0$2f3q$1...@digitalmars.com
> I did this in 2 January
> (http://forum.dlang.org/thread/lpljpfjxwobniglwn...@forum.dlang.org) and
> received exactly
On Tuesday, 29 October 2013 at 17:57:01 UTC, Ali Çehreli wrote:
On 10/29/2013 08:47 AM, Maxim Fomin wrote:
On Monday, 28 October 2013 at 20:43:01 UTC, Ali Çehreli wrote:
What is the purpose of writeln in that delegate? Obviously,
to print
1. Yet it doesn't happen that way. Is this accepted to
On 10/29/2013 08:47 AM, Maxim Fomin wrote:
On Monday, 28 October 2013 at 20:43:01 UTC, Ali Çehreli wrote:
What is the purpose of writeln in that delegate? Obviously, to print
1. Yet it doesn't happen that way. Is this accepted to be a bug?
Should the programmer 'new' the object instead?
Ali
On Tuesday, 29 October 2013 at 12:03:09 UTC, Rene Zwanenburg
wrote:
On Monday, 28 October 2013 at 19:40:26 UTC, Maxim Fomin wrote:
The fact that structs are movable and there is too few struct
runtime reflection makes them noncollectable. However, you can
wrap struct inside class, in such case
On Tuesday, 29 October 2013 at 11:46:53 UTC, Rene Zwanenburg
wrote:
That's pretty nasty :). But I suspect this is a bug and not by
design. __dtor and __traits are, IMHO, the proverbial escape
hatch D should provide, so I think that's OK. I take it that by
control flow trick you mean the try/c
On Monday, 28 October 2013 at 20:43:01 UTC, Ali Çehreli wrote:
What is the purpose of writeln in that delegate? Obviously, to
print 1. Yet it doesn't happen that way. Is this accepted to be
a bug? Should the programmer 'new' the object instead?
Ali
In my opinion it is a corner case, a cons
On Monday, 28 October 2013 at 19:40:26 UTC, Maxim Fomin wrote:
The fact that structs are movable and there is too few struct
runtime reflection makes them noncollectable. However, you can
wrap struct inside class, in such case struct dtor will be
called.
Yeah, if wrapping inside a class would
On Monday, 28 October 2013 at 19:30:12 UTC, Maxim Fomin wrote:
Here is my attempt:
import std.stdio;
struct S
{
int i;
this(int i) { writefln("ctor, %X", i); this.i = i; }
this(this) { writefln("postblit, %X, %X", &this, i); }
~this() { writefln("dtor, %X, %X", &this, i); }
}
On 10/28/2013 12:30 PM, Maxim Fomin wrote:
> So do you *know* cases or suspect that they may exists? Or remember some
> bug issue?
>
> Here is my attempt:
>
> import std.stdio;
>
> struct S
> {
> int i;
> this(int i) { writefln("ctor, %X", i); this.i = i; }
> this(this) { writefln(
On Monday, 28 October 2013 at 10:07:15 UTC, Rene Zwanenburg wrote:
On Sunday, 27 October 2013 at 23:33:55 UTC, Ali Çehreli wrote:
That's news to me. I know that objects may never be destroyed
but why multiple times? How many lives do they have? ;)
Yeah, I'd like to know this as well. I do reme
On Monday, 28 October 2013 at 16:53:11 UTC, monarch_dodra wrote:
On Monday, 28 October 2013 at 10:07:15 UTC, Rene Zwanenburg
wrote:
Yeah, I'd like to know this as well. I do remember structs
allocated on the heap don't have their destructors called at
all due to the GC not being precise, I thin
On Monday, 28 October 2013 at 10:07:15 UTC, Rene Zwanenburg wrote:
Yeah, I'd like to know this as well. I do remember structs
allocated on the heap don't have their destructors called at
all due to the GC not being precise, I think.
But one object allowed to be destructed multiple times? That
On Sunday, 27 October 2013 at 23:33:55 UTC, Ali Çehreli wrote:
On 10/27/2013 03:04 PM, monarch_dodra wrote:
> it *could* be an (older) emplace bug. Do you reproduce with
head?
I had tested it with head. No, doesn't happen on head.
Thanks for testing that. I'm not set up to build dmd or phobos
On 10/27/2013 03:04 PM, monarch_dodra wrote:
> it *could* be an (older) emplace bug. Do you reproduce with head?
I had tested it with head. No, doesn't happen on head.
> Also, keep in mind that DMD *is* allowed to destroy the same
> object several times.
That's news to me. I know that objects
On Sunday, 27 October 2013 at 21:02:01 UTC, Rene Zwanenburg wrote:
On Thursday, 24 October 2013 at 16:46:37 UTC, Ali Çehreli wrote:
Technically, it is a problem with FooWrapper. Regardless of
whether RefCounted's behavior, by default, structs in D are
freely copyable and movable value types. Th
On Thursday, 24 October 2013 at 16:46:37 UTC, Ali Çehreli wrote:
Technically, it is a problem with FooWrapper. Regardless of
whether RefCounted's behavior, by default, structs in D are
freely copyable and movable value types. The compiler can do
those things as it sees fit.
Since FooWrapper o
On Thursday, 24 October 2013 at 16:40:42 UTC, Jesse Phillips
wrote:
I answered a question related to RefCount on SO
http://stackoverflow.com/questions/4632355/making-a-reference-counted-object-in-d-using-refcountedt/4635050#4635050
Not written to your specific problem, but may give you the
info
ed by createFoo(), when the Bar instance goes out of scope. Current
behaviour causes an invalid pointer to be passed to destroyFoo(). Is
this a bug in RefCounted or am I doing something wrong?
Technically, it is a problem with FooWrapper. Regardless of whether
RefCounted's behavior, by default, str
y
once, on the instance created by createFoo(), when the Bar
instance goes out of scope. Current behaviour causes an invalid
pointer to be passed to destroyFoo(). Is this a bug in
RefCounted or am I doing something wrong?
I answered a question related to RefCount on SO
http://stackoverflow.com/qu
es out of scope. Current behaviour causes an invalid pointer to
be passed to destroyFoo(). Is this a bug in RefCounted or am I
doing something wrong?
21 matches
Mail list logo
