www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - How to turn this C++ into D?

reply "Patrick Jeeves" <pdj9 pitt.edu> writes:
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::list<foo*> foo_list;
typedef std::list<foo*>::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.
Nov 05 2014
next sibling parent reply "luminousone" <rd.hunt gmail.com> writes:
On Wednesday, 5 November 2014 at 17:17:11 UTC, Patrick Jeeves 
wrote:
 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::list<foo*> foo_list;
 typedef std::list<foo*>::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.
abstract class foo { static DList!foo foo_list; this() { if( foo_list is null ) foo_list = make!(DList!foo); foo_list.insert(this); } ~this(){ foo_list.remove(this); } static void DO_TASK() { foreach( i ; foo_list ) { i.process(); } foreach( i ; foo_list ) { i.advance(); } } abstract void process(); abstract void advance(); } note that static is thread local in D, so foo_list would be unique per thread, if you want it globally unique then you need to pull it out of the class and market it __gshared foo_list; Also no need to mark functions as virtual, as dlang is currently virtual by default rather then final by default, for best optimization be sure to mark functions as final when possible.
Nov 05 2014
parent "thedeemon" <dlang thedeemon.com> writes:
On Wednesday, 5 November 2014 at 17:45:00 UTC, luminousone wrote:
 abstract class foo {
     static DList!foo foo_list;
     ~this(){ foo_list.remove(this); }
One note: when your program exits the runtime does a final GC cycle and collects those things calling destructors/finalizers, however the static data can easily be already collected/destructed at this moment, so attempting to access it from object's finalizer will crash. One should not ever access any reference types and data outside the object itself from a destructor/finalizer.
Nov 06 2014
prev sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 11/05/2014 09:17 AM, Patrick Jeeves wrote:

 class foo
 {
 static std::list<foo*> foo_list;
 typedef std::list<foo*>::iterator iterator;
 public:
      foo()
      {
         foo_list.push_back(this);
      }
      ~foo()
      {
         foo_list.remove(this);
      }
Going completely off-topic, I recommend against objects registering themselves that way. That idiom has caused trouble in more than one project for us. In general, I think a constructor should not have side-effects unless needed for the object's construction (e.g. allocating a resource for the object should obviously fine). Ali
Nov 05 2014
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 11/05/2014 10:07 AM, Ali Çehreli wrote:

 On 11/05/2014 09:17 AM, Patrick Jeeves wrote:

  > class foo
  > {
  > static std::list<foo*> foo_list;
  > typedef std::list<foo*>::iterator iterator;
  > public:
  >      foo()
  >      {
  >         foo_list.push_back(this);
  >      }
Argh! I forgot to add an important, perhaps philosophical, point. :) Continuing the off-topic, an object should be considered constructed only after hitting that closing curly bracket above. If so, then that push_back would be adding an incomplete object to the list. Ali
Nov 05 2014
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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)? But the D translation worries me too because the destructor won't run at the same time as the C++ version, unless you make it a scope class or something.
Nov 05 2014
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
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
Nov 05 2014
parent reply "luminousone" <rd.hunt gmail.com> writes:
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.
Nov 05 2014
parent reply "Patrick Jeeves" <pdj9 pitt.edu> writes:
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?
Nov 05 2014
next sibling parent reply "luminousone" <rd.hunt gmail.com> writes:
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.
Nov 05 2014
parent reply "Patrick Jeeves" <pdj9 pitt.edu> writes:
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?
Nov 05 2014
parent "luminousone" <rd.hunt gmail.com> writes:
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.
Nov 05 2014
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/5/14 2:05 PM, 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.
Allocate the list with stdc.malloc. It won't be tracked by the GC. However, note that such accesses need to be synchronized, because the GC can run in any thread, and be sure that list is shared or __gshared. Now, another problem with making it untracked by the GC, you need a list object with a custom allocator. Which I don't think we have yet, you'd likely have to invent this too.
 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?
This was never the case. The runtime is guaranteed to call the destructor only once. In order to do this, when the object is finalized, it's vtable pointer is nulled. So it effectively becomes unusable. This is the same thing for destroy. BTW, be very very careful with destructors. They should ONLY be used to manage NON-GC resources. In this example, if you C malloc the list, you can access it in the dtor. -Steve
Nov 06 2014