On Sunday 15 August 2010 10:10:29 bearophile wrote:
> Max Samukha:
> > We tried to impose management of all QtD objects on the user but that
> > proved to be a bad idea. The exception is QObject. In Qt QObjects are
> > arranged in trees. When the root node is destroyed all its children are
> > dest
Max Samukha:
> We tried to impose management of all QtD objects on the user but that
> proved to be a bad idea. The exception is QObject. In Qt QObjects are
> arranged in trees. When the root node is destroyed all its children are
> destroyed as well. GC is disabled for QObjects.
I think Phobos
On 08/13/2010 12:07 AM, Michel Fortin wrote:
Here is a real-world example: the D/Objective-C bridge use a class
destructor/finalizer to release the Objective-C counterpart of a wrapper
(by calling the release method on the Objective-C object). The
Objective-C object is not something I can alloca
Perhaps relevant to this discussion is the Old New Thing posts this
week. This last one has a good sentence:
http://blogs.msdn.com/b/oldnewthing/archive/2010/08/13/10049634.aspx
"If I ruled the world, I would decree that the only thing you can do
in a finalizer is perform some tests to ensure tha
On Thu, 12 Aug 2010 16:08:17 -0400, Don wrote:
Steven Schveighoffer wrote:
On Thu, 12 Aug 2010 13:05:53 -0400, Joe Greer
wrote:
"Steven Schveighoffer" wrote in
news:op.vhbtwjhoeav...@localhost.localdomain:
Logically speaking if an object isn't destructed, then it lives
forever and if i
On 2010-08-12 16:08:17 -0400, Don said:
That's the only example of an nearly unlimited resource which I've
heard thus far, but that raises the question, why the hell would you be
using malloc if you're not going to free it, when you have a language
with a gc? Effectively, the gc is freeing yo
Steven Schveighoffer wrote:
On Thu, 12 Aug 2010 13:05:53 -0400, Joe Greer
wrote:
"Steven Schveighoffer" wrote in
news:op.vhbtwjhoeav...@localhost.localdomain:
Logically speaking if an object isn't destructed, then it lives
forever and if it continues to hold it's resource, then we have a
p
On 2010-08-12 15:18:33 -0400, "Steven Schveighoffer"
said:
On Thu, 12 Aug 2010 13:05:53 -0400, Joe Greer wrote:
I think you misunderstand what I was saying. The compiler doesn't decide
any of that. The programmer conserned with correctness has the option of
making his finalizer complain
On Thu, 12 Aug 2010 13:05:53 -0400, Joe Greer
wrote:
"Steven Schveighoffer" wrote in
news:op.vhbtwjhoeav...@localhost.localdomain:
Logically speaking if an object isn't destructed, then it lives
forever and if it continues to hold it's resource, then we have a
programming error. The GC is
"Steven Schveighoffer" wrote in
news:op.vhbtwjhoeav...@localhost.localdomain:
>> Logically speaking if an object isn't destructed, then it lives
>> forever and if it continues to hold it's resource, then we have a
>> programming error. The GC is for reclaiming memory, not files. It
>> can take
On 8/12/2010 06:59, Joe Greer wrote:
> Logically speaking if an object isn't destructed, then it lives forever
> and if it continues to hold it's resource, then we have a programming
> error. The GC is for reclaiming memory, not files. It can take a long
> time for a GC to reclaim an object an
On Thu, 12 Aug 2010 08:59:31 -0400, Joe Greer
wrote:
"Steven Schveighoffer" wrote in
news:op.vhbpkcaieav...@localhost.localdomain:
Destructors as they are now are too limited, because they cannot be
sure they are being called by the GC or not, they must assume so. So
in one sense I agr
"Steven Schveighoffer" wrote in
news:op.vhbpkcaieav...@localhost.localdomain:
>
> Destructors as they are now are too limited, because they cannot be
> sure they are being called by the GC or not, they must assume so. So
> in one sense I agree with you. But in another sense, we *still* need
On Wed, 11 Aug 2010 16:14:56 -0400, Don wrote:
Michel Fortin wrote:
On 2010-08-11 15:09:45 -0400, Jonathan M Davis
said:
On Wednesday, August 11, 2010 11:33:54 Michel Fortin wrote:
I'm not too sure that'll work very well. I think a better solution
would be to have a way to distinguish be
On 2010-08-11 17:08:49 -0400, Walter Bright said:
Jonathan M Davis wrote:
This needs to be sorted out in a manner that minimizes how much pain it
causes for the typical programmer in their typical programming tasks.
Destructors should not be this much trouble.
I agree. Having too many inter
Jonathan M Davis wrote:
This needs to be sorted out in a manner that minimizes how much pain it causes
for the typical programmer in their typical programming tasks. Destructors
should not be this much trouble.
I agree. Having too many interacting options just winds up confusing the heck
out
On 2010-08-11 16:26:58 -0400, bearophile said:
But if the purpose of a destructor is just to help/speedup the
deallocation of a RAM resource (like to nullify the links of a tree to
speed up the job of the GC) then in my opinion it is acceptable for
this destructor to not run deterministically
On 2010-08-11 16:14:56 -0400, Don said:
Michel Fortin wrote:
Sure, and now you can't use std.containers.Array as a member in a
Class, neither std.stdio.File, etc. Is there something left classes can
do?
As far as I can tell, the use cases for finalizers are very limited. To
me, destructors
On Wednesday, August 11, 2010 13:14:56 Don wrote:
> As far as I can tell, the use cases for finalizers are very limited. To
> me, destructors don't make any sense unless they are deterministic.
> For example, I think having a File class is probably a bug. You may be
> on a system which has no limit
Don:
> As far as I can tell, the use cases for finalizers are very limited. To
> me, destructors don't make any sense unless they are deterministic.
> For example, I think having a File class is probably a bug. You may be
> on a system which has no limit on the number of file handles, but
> gene
On Wednesday, August 11, 2010 12:43:10 Michel Fortin wrote:
> On 2010-08-11 15:09:45 -0400, Jonathan M Davis said:
> > On Wednesday, August 11, 2010 11:33:54 Michel Fortin wrote:
> >> I'm not too sure that'll work very well. I think a better solution
> >> would be to have a way to distinguish betw
Michel Fortin wrote:
On 2010-08-11 15:09:45 -0400, Jonathan M Davis
said:
On Wednesday, August 11, 2010 11:33:54 Michel Fortin wrote:
I'm not too sure that'll work very well. I think a better solution
would be to have a way to distinguish between a struct that can be put
on the GC heap and o
On 2010-08-11 15:09:45 -0400, Jonathan M Davis said:
On Wednesday, August 11, 2010 11:33:54 Michel Fortin wrote:
I'm not too sure that'll work very well. I think a better solution
would be to have a way to distinguish between a struct that can be put
on the GC heap and one that cannot. A struc
Jonathan M Davis wrote in
news:mailman.260.1281553632.13841.digitalmar...@puremagic.com:
> On Wednesday, August 11, 2010 11:33:54 Michel Fortin wrote:
>> I'm not too sure that'll work very well. I think a better solution
>> would be to have a way to distinguish between a struct that can be
>> pu
On Wednesday, August 11, 2010 11:33:54 Michel Fortin wrote:
> I'm not too sure that'll work very well. I think a better solution
> would be to have a way to distinguish between a struct that can be put
> on the GC heap and one that cannot. A struct that cannot go on the GC
> heap make it safe to ac
On 2010-08-11 13:10:08 -0400, Jonathan M Davis said:
The more this whole issue gets discussed, the less it seems like I know about
the issue. It's just too complicated to be immediately understandable.
Personally, I think that the very fact that it's possible to access references
which are no l
On Wednesday, August 11, 2010 07:08:27 Steven Schveighoffer wrote:
> I agree with what Michael suggested that destructors should be restricted
> to unsafe D.
The more this whole issue gets discussed, the less it seems like I know about
the issue. It's just too complicated to be immediately unders
On Wed, 11 Aug 2010 10:03:41 -0400, foobar wrote:
Steven Schveighoffer Wrote:
On Tue, 10 Aug 2010 20:28:32 -0400, bearophile
wrote:
> Jonathan M Davis:
>> If attempts to use any reference types in destructors were a
>> compile-time error
>> with a clear error message, that could go a long
On 2010-08-11 09:03:53 -0400, "Steven Schveighoffer"
said:
The problem is, you don't know from the type system that they are
heap-allocated, and the compiler cannot know what is owned and what is
not owned, so it can't make the call to restrict you.
Indeed, that's a real problem.
And I'm
On Wed, 11 Aug 2010 09:53:24 -0400, foobar wrote:
Steven Schveighoffer Wrote:
So if a struct has a class reference, it cannot clean it up? What if
the
class contains a struct that has an open file reference, and you want to
clean up that file immediately? What if that class is private an
Steven Schveighoffer Wrote:
> On Tue, 10 Aug 2010 20:28:32 -0400, bearophile
> wrote:
>
> > Jonathan M Davis:
> >> If attempts to use any reference types in destructors were a
> >> compile-time error
> >> with a clear error message, that could go a long way in stopping people
> >> from
> >
Steven Schveighoffer Wrote:
> So if a struct has a class reference, it cannot clean it up? What if the
> class contains a struct that has an open file reference, and you want to
> clean up that file immediately? What if that class is private and the
> struct knows that there are no other
On Tue, 10 Aug 2010 20:28:32 -0400, bearophile
wrote:
Jonathan M Davis:
If attempts to use any reference types in destructors were a
compile-time error
with a clear error message, that could go a long way in stopping people
from
trying to misuse destructors.
This sounds like a positive
On Wed, 11 Aug 2010 03:12:57 -0400, foobar wrote:
Rainer Deyke Wrote:
On 8/10/2010 16:59, foobar wrote:
> Steven Schveighoffer Wrote:
>> what happens when GC destroys a C?
>>
>> C::~this(); // auto generated
>> B::~this(); // so good so far
>> A::~this(); // oops! the a is gone, progra
Rainer Deyke Wrote:
> On 8/10/2010 16:59, foobar wrote:
> > Steven Schveighoffer Wrote:
> >> what happens when GC destroys a C?
> >>
> >> C::~this(); // auto generated
> >> B::~this(); // so good so far
> >> A::~this(); // oops! the a is gone, program vomits bits all over
> >> itself and
On 8/10/2010 16:59, foobar wrote:
> Steven Schveighoffer Wrote:
>> what happens when GC destroys a C?
>>
>> C::~this(); // auto generated
>> B::~this(); // so good so far
>> A::~this(); // oops! the a is gone, program vomits bits all over itself
>> and
>> chokes to death.
>>
>> -Steve
>
Jonathan M Davis:
> If attempts to use any reference types in destructors were a compile-time
> error
> with a clear error message, that could go a long way in stopping people from
> trying to misuse destructors.
This sounds like a positive idea, maybe fit for an enhancement request.
Bye,
bear
On 2010-08-10 19:58:08 -0400, Jonathan M Davis said:
On Tuesday, August 10, 2010 16:15:33 foobar wrote:
I agree :)
In general, the rule is that destructors can only access value types. This
can be enforced at compile time. Also, I was using structs and classes in
my examples but this should b
On Tuesday, August 10, 2010 16:15:33 foobar wrote:
> I agree :)
>
> In general, the rule is that destructors can only access value types. This
> can be enforced at compile time. Also, I was using structs and classes in
> my examples but this should be understood as value types vs. reference
> type
Michel Fortin Wrote:
> On 2010-08-10 18:39:03 -0400, "Steven Schveighoffer"
> said:
>
> > It's only safe if the struct destructor does not deallocate any heap data.
>
> To be even clearer, it's only safe if the struct destructor doesn't
> access any heap data through one of its members.
>
>
On 2010-08-10 18:51:24 -0400, Lutger said:
This is what I proposed, but the other way around and the semantics of
~~this implemented by an interface. If we keep ~this as the finalizer,
the language need not to change so it will not impact existing code too
much.
Perhaps you're right, but I
Steven Schveighoffer Wrote:
> On Tue, 10 Aug 2010 18:09:53 -0400, foobar wrote:
>
> > Steven Schveighoffer Wrote:
> >
> >> So either you are saying that structs that are in classes are never
> >> destroyed, and you have a resource leak, or every class has an
> >> auto-generated destructor that c
On 2010-08-10 18:39:03 -0400, "Steven Schveighoffer"
said:
It's only safe if the struct destructor does not deallocate any heap data.
To be even clearer, it's only safe if the struct destructor doesn't
access any heap data through one of its members.
And accessing an array or a string cou
Michel Fortin wrote:
> On 2010-08-10 17:23:39 -0400, foobar said:
>
>> Steven Schveighoffer Wrote:
>>
>>> That doesn't help. deterministic destruction is not a struct-vs-class
>>> problem, its a GC-vs-manual-memory problem. A struct on the heap that is
>>> finalized by the GC has the same iss
On Tue, 10 Aug 2010 18:09:53 -0400, foobar wrote:
Steven Schveighoffer Wrote:
So either you are saying that structs that are in classes are never
destroyed, and you have a resource leak, or every class has an
auto-generated destructor that calls the struct destructors, and we have
the same de
Steven Schveighoffer Wrote:
> On Tue, 10 Aug 2010 17:23:39 -0400, foobar wrote:
>
> > Steven Schveighoffer Wrote:
> >
> >> On Tue, 10 Aug 2010 16:33:08 -0400, foo wrote:
> >>
> >> > In light on recent discussions of clear() and the distructor it seems
> >> to
> >> > me that we are going backw
On 2010-08-10 17:23:39 -0400, foobar said:
Steven Schveighoffer Wrote:
That doesn't help. deterministic destruction is not a struct-vs-class
problem, its a GC-vs-manual-memory problem. A struct on the heap that is
finalized by the GC has the same issues as a class destructor. In fact,
stru
On Tue, 10 Aug 2010 17:23:39 -0400, foobar wrote:
Steven Schveighoffer Wrote:
On Tue, 10 Aug 2010 16:33:08 -0400, foo wrote:
> In light on recent discussions of clear() and the distructor it seems
to
> me that we are going backwards from one of D's great improvements over
> C++ - the dif
Steven Schveighoffer Wrote:
> On Tue, 10 Aug 2010 16:33:08 -0400, foo wrote:
>
> > In light on recent discussions of clear() and the distructor it seems to
> > me that we are going backwards from one of D's great improvements over
> > C++ - the difference in semantics between structs and cla
On Tue, 10 Aug 2010 16:33:08 -0400, foo wrote:
In light on recent discussions of clear() and the distructor it seems to
me that we are going backwards from one of D's great improvements over
C++ - the difference in semantics between structs and classes.
IMO, instead of enhancing class dest
In light on recent discussions of clear() and the distructor it seems to me
that we are going backwards from one of D's great improvements over C++ - the
difference in semantics between structs and classes.
IMO, instead of enhancing class desteructors they should be completely removed
and only
51 matches
Mail list logo
