On Sunday, 4 May 2014 at 16:13:23 UTC, Andrei Alexandrescu wrote:
On 5/4/14, 4:42 AM, Marc Schütz schue...@gmx.net wrote:
But I'm afraid your suggestion is unsafe: There also needs to
be a way
to guarantee that no references to the scoped object exist
when it is
destroyed.
Actually, it
Very short feedback about original proposal:
1) managing local objects is not really a problem, we already
have `scoped` in Phobos for that (and unimplemented scope
qualifier as possible more reliable approach)
2) real problem is managing global objects without clear
destruction point while
On 5/5/14, 3:18 AM, Marc Schütz schue...@gmx.net wrote:
On Sunday, 4 May 2014 at 16:13:23 UTC, Andrei Alexandrescu wrote:
On 5/4/14, 4:42 AM, Marc Schütz schue...@gmx.net wrote:
But I'm afraid your suggestion is unsafe: There also needs to be a way
to guarantee that no references to the scoped
On 2014-05-03 14:28, monnoroch wrote:
That leaves only to determine, what objects are scoped. Well, that is
obviously stack-allocated structs, gc-allocated scope classes and
gc-allocated structs in scope classes.
Will the destructor of GC allocated scope classes be called when its
On Saturday, 3 May 2014 at 12:28:03 UTC, monnoroch wrote:
Back to the dtors: i understand, that all the stuff you propose
could make GC faster, simpler, and cooler,
Note that this is _not_ the motivation behind the discussed
changes. It's primarily about correctness and consistency. What
we
On Sunday, 4 May 2014 at 11:42:14 UTC, Marc Schütz wrote:
On Saturday, 3 May 2014 at 12:28:03 UTC, monnoroch wrote:
Back to the dtors: i understand, that all the stuff you
propose could make GC faster, simpler, and cooler,
Note that this is _not_ the motivation behind the discussed
changes.
On 5/4/14, 4:42 AM, Marc Schütz schue...@gmx.net wrote:
But I'm afraid your suggestion is unsafe: There also needs to be a way
to guarantee that no references to the scoped object exist when it is
destroyed.
Actually, it should be fine to call the destructor, then blast T.init
over the
I've been reading all the topics with those radical ideas about
the GC and dtors and, honestly, i'd rather call them insane.
After all the reading and thinking, i came to conclusion, that
what Andrey suggests is to call dtors only on stack-allocated
structs. That also implies, that one can't
On Saturday, 3 May 2014 at 12:28:03 UTC, monnoroch wrote:
I've been reading all the topics with those radical ideas
about the GC and dtors and, honestly, i'd rather call them
insane. After all the reading and thinking, i came to
conclusion, that what Andrey suggests is to call dtors only on
Hey I have this global variable, if I assign a value to it and
later null it, it'll call its destructor if its not referenced
anywhere else.
Which in turn would make me think ref counting would be a good
idea.
It seems, that ARC is the only way. There were idea to make all
non-scoped (in
Scoped-objects + ARC on non-scoped objects with dtors + GC on
non-scoped objects w/o dtors would arguably solve the problem,
especially, is arrays of scoped objects would be considered also
scoped, or just add separate scoped arrays.
Am 03.05.2014 14:28, schrieb monnoroch:
I've been reading all the topics with those radical ideas about the GC
and dtors and, honestly, i'd rather call them insane. After all the
reading and thinking, i came to conclusion, that what Andrey suggests is
to call dtors only on stack-allocated
On Saturday, 3 May 2014 at 13:21:04 UTC, Paulo Pinto wrote:
C# and Java also have scoped blocks (using,
try-with-resources), similar to Python for resource management.
Yeah, but it doesn't work for graphs that maintain resources,
such as a scene graph which hold onto texture memory.
Am 03.05.2014 16:02, schrieb Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com:
On Saturday, 3 May 2014 at 13:21:04 UTC, Paulo Pinto wrote:
C# and Java also have scoped blocks (using, try-with-resources),
similar to Python for resource management.
Yeah, but it doesn't work for graphs
On Saturday, 3 May 2014 at 14:31:59 UTC, Paulo Pinto wrote:
- Make all scene graph nodes IDisposable.
- Have a using(rootNode) {} on your render loop
That would work for a static scene.
But you want to mark resources ready for release when nodes are
removed from the graph dynamically. In
Am 03.05.2014 16:43, schrieb Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com:
On Saturday, 3 May 2014 at 14:31:59 UTC, Paulo Pinto wrote:
- Make all scene graph nodes IDisposable.
- Have a using(rootNode) {} on your render loop
That would work for a static scene.
But you want to
On Saturday, 3 May 2014 at 15:10:43 UTC, Paulo Pinto wrote:
Easy, you already know that you don't need the node, just call
the dispose method, instead of marking for release.
But you don't know unless you use RC or GC. Let's say you make a
jungle. Lots of pointers to the tree root node. And
Am 03.05.2014 17:20, schrieb Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com:
On Saturday, 3 May 2014 at 15:10:43 UTC, Paulo Pinto wrote:
Easy, you already know that you don't need the node, just call the
dispose method, instead of marking for release.
But you don't know unless you
On 5/3/14, 5:39 AM, monnoroch wrote:
Hey I have this global variable, if I assign a value to it and later
null it, it'll call its destructor if its not referenced anywhere else.
Which in turn would make me think ref counting would be a good idea.
It seems, that ARC is the only way. There
On Saturday, 3 May 2014 at 18:27:46 UTC, Andrei Alexandrescu
wrote:
On 5/3/14, 5:39 AM, monnoroch wrote:
Hey I have this global variable, if I assign a value to it
and later
null it, it'll call its destructor if its not referenced
anywhere else.
Which in turn would make me think ref counting
Interesting, we haven't explored that. The most problematic
implication would be that classes with destructors will form a
hierarchy separate from Object.
As i understood, you want to remove dtors for non-scoped objects
completely, so all classes will be without it, except user
defined ones.
The most problematic implication would be that classes with
destructors will form a hierarchy separate from Object.
What for? As i understand object's dtor does nothing, so for any
class we can determine, if dtor is empty. I don't see a problem
here.
Cycles and locks for RC are the biggest
On 2014-05-03 18:27:47 +, Andrei Alexandrescu
seewebsiteforem...@erdani.org said:
Interesting, we haven't explored that. The most problematic implication
would be that classes with destructors will form a hierarchy separate
from Object.
Seems like people have been ignoring my two posts
23 matches
Mail list logo
