Re: GC and MMM

2015-08-20 Thread luminousone via Digitalmars-d-learn
On Thursday, 20 August 2015 at 17:13:33 UTC, Ilya Yaroshenko 
wrote:

Hi All!

Does GC scan manually allocated memory?
I want to use huge manually allocated hash tables and I don't 
want to GC scan them because performance reasons.


Best regards,
Ilya


Yes, just don't store any GC managed pointers in said manually 
allocated memory. Or at the very least consider any GC managed 
pointers to be weak pointers.


core.memory add/remove range have to be used put c malloc memory 
into the GC, simply don't call these functions.


Re: How to turn this C++ into D?

2014-11-05 Thread luminousone via Digitalmars-d-learn

On Wednesday, 5 November 2014 at 18:18:18 UTC, Ali Çehreli wrote:

On 11/05/2014 10:12 AM, Adam D. Ruppe wrote:

 On Wednesday, 5 November 2014 at 18:10:38 UTC, Ali Çehreli
wrote:
 If so, then that push_back would be adding an incomplete
object to the
 list.

 scope(success)?

I really like that! :)

But still not for this case because in addition to the problem 
with the destruction order, I would like to feel free to remove 
unused objects like the following without worrying about 
side-effects:


// C++ code
void bar()
{
Foo seemingly_unused_here();
// ...
}

Ali


unless delete is explicitly called, I don't believe the 
destructor would ever be called, it would still have a reference 
in the static foo_list object that would stop it from being 
collected by the gc.


I could see the constructor situation being a problem in threaded 
code as well, tho it may be bad practice, I don't believe the 
insert(this) would actually break anything.


The scope(success) is a good idea either way however.


Re: How to turn this C++ into D?

2014-11-05 Thread luminousone via Digitalmars-d-learn
On Wednesday, 5 November 2014 at 19:05:32 UTC, Patrick Jeeves 
wrote:
On Wednesday, 5 November 2014 at 18:56:08 UTC, luminousone 
wrote:
unless delete is explicitly called, I don't believe the 
destructor would ever be called, it would still have a 
reference in the static foo_list object that would stop it 
from being collected by the gc.


This is exactly why I asked about it, and even if delete is 
explicitly called-- which i believe is deprecated, wouldn't the 
runtime fill the space with the default construtor until the GC 
decides to remove it? meaning it would be immediatly added back 
into the list?


I don't believe that the default constructor is called. I am 
pretty sure delete immediately deallocates the object, 
deregistering its memory from the gc.


In fact I am 99% sure no constructor is called after delete, it 
would cause problems for objects with no default constructor, or 
for system related stuff done in constructors, and I haven't seen 
anything like that in my X11 work in d.




Re: How to turn this C++ into D?

2014-11-05 Thread luminousone via Digitalmars-d-learn
On Wednesday, 5 November 2014 at 20:31:54 UTC, Patrick Jeeves 
wrote:
On Wednesday, 5 November 2014 at 19:44:57 UTC, luminousone 
wrote:
On Wednesday, 5 November 2014 at 19:05:32 UTC, Patrick Jeeves 
wrote:
On Wednesday, 5 November 2014 at 18:56:08 UTC, luminousone 
wrote:
unless delete is explicitly called, I don't believe the 
destructor would ever be called, it would still have a 
reference in the static foo_list object that would stop it 
from being collected by the gc.


This is exactly why I asked about it, and even if delete is 
explicitly called-- which i believe is deprecated, wouldn't 
the runtime fill the space with the default construtor until 
the GC decides to remove it? meaning it would be immediatly 
added back into the list?


I don't believe that the default constructor is called. I am 
pretty sure delete immediately deallocates the object, 
deregistering its memory from the gc.


In fact I am 99% sure no constructor is called after delete, 
it would cause problems for objects with no default 
constructor, or for system related stuff done in constructors, 
and I haven't seen anything like that in my X11 work in d.


I guess I got confused by something... I don't know.  But what 
I'd really like is for it to be garbage colleceted when no 
references outside of that static array exist, as i mentioned 
at the bottom of my first post.  I illustrated my example with 
that specific class because when i looked up weak pointers on 
the site I found discussions getting caught up with how to 
avoid dangling pointers when weak pointers are used; and I 
wanted to illustrate that that's a non-issue in this case, 
because I wasn't sure how much that contributed to the 
solutions given.


I suppose it doesn't matter because this is based on something 
I do with multiple inheritance in C++, I felt like I may be 
able to get it to work in D because the only public members of 
those classes were always pure virtual functions.


As an aside, how does scope(success) work in the context of a 
constructor? given:


abstract class foo
{
this()
{
   scope(success) onAdd();
}
~this()
{
   onRemove();
}

onAdd();
onRemove();
}

class bar : foo
{
int _a;

this(int a)
{
   _a = a;
}

void onAdd(){ writeln(_a); }
void onRemove() { writeln(_a); }
}

is _a defined as anything in either of writes? or would it be 
called at the wrong time relative to setting _a?


As of yet their are no built in weak references/pointers, you can 
jerry rig them however.


constructors will implicitly call super at the top of the 
function if no super call is made within the function body, so


this( int a ) {
//  super(); is called here if not defined below
_a = a;
}

I'd really like is for it to be garbage colleceted when no 
references outside of that static array exist, as i mentioned 
at the bottom of my first post.


Can't easily do this yet, would require you writing your own list 
class, as std.container, does not have any way of passing an 
allocator to it.


They are coming, slowly but surely we will eventually have them.

Allocators would allow container classes to create objects(nodes 
and such) that are in memory that is not scanned by the garbage 
collector.


You can in fact allocate memory manually right now, via 
std.c.memory or std.c.stdlib (don't member which one has c malloc 
and free).


Just be sure to familiarize your self with the manual gc 
registration and deregistration functions in core.memory.