How to turn this C++ into D?

2014-11-05 Thread Patrick Jeeves via Digitalmars-d-learn
So this is more a stackoverflow question, but I feel like later 
searchers will be more likely to find it if I put it here.


if I have the following C++ code:

class foo
{
static std::listfoo* foo_list;
typedef std::listfoo*::iterator iterator;
public:
foo()
{
   foo_list.push_back(this);
}
~foo()
{
   foo_list.remove(this);
}

static void DO_TASK()
{
for(iterator i = foo_list.begin(); i  foo_list.end(); 
++i)

{
(*i)-process();
}

for(iterator i = foo_list.begin(); i  foo_list.end(); 
++i)

{
(*i)-advance();
}
}

virtual void process() = 0;
virtual void advance() = 0;
}

How can I turn this into D?  Is there a way to register that 
static list with the garbage collector so it doesn't look into it 
or anything?


Similarly, I feel like this would be an interface in D, but 
interfaces don't have constructors.


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

2014-11-05 Thread Patrick Jeeves via Digitalmars-d-learn

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?


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

2014-11-05 Thread Patrick Jeeves via Digitalmars-d-learn

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?


Curiously Cyclic Template Pattern causes segfault?

2014-11-05 Thread Patrick Jeeves via Digitalmars-d-learn


When I tried to test out the following code the compiler 
segfaulted:



interface BarBase
{
void do_a_thing();
}

interface Bar(T) : BarBase
{
	static if(hasMember!(T, rotation)  is(typeof(T.rotation) == 
double))

{
@property
double rotation();

final void do_a_thing()
{
//do a thing with rotation;
}
}
else
{
final void do_a_thing()
{
//do a thing without rotation;
}
}
}

class Foo1 : Bar!Foo1
{
}

class Foo2 : Bar!Foo2
{
@property
double rotation() { return 1.0; };
}

Is there some rule against doing this or is it a glitch?