www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Defining a custom *constructor* (not initializer!)

reply "Mehrdad" <wfunction hotmail.com> writes:
Is this possible in D2?

i.e. I'm wondering if there is a way to do the object
construction yourself, which would allow you to call the object's
"constructor" (initializer) manually, and just return a pointer
to the new object.

Something along the lines of:

	class Window
	{
		static Window opConstruct(void* ptr)
		{
			// Assume ptr is already correctly sized and filled
			Window result = cast(Window)ptr;
			result.__ctor();
			return return result;
		}
	}

It seems like overloading new() *almost* does this, but not
quite: It only lets you allocate the memory, not call the
constructor yourself.

This would be useful, because some objects can have external
constructors (notably when interfacing with C/C++, such as when
using CreateWindow() in Windows), and you *cannot* call these
constructors inside the object's "constructor" (initializer) due
to re-entrancy issues.
May 06 2012
next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
Oh, and add "custom destructors" to that question as well: static 
methods that call ~this() manually on the object.
May 06 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-05-06 21:55, Mehrdad wrote:
 Is this possible in D2?

 i.e. I'm wondering if there is a way to do the object
 construction yourself, which would allow you to call the object's
 "constructor" (initializer) manually, and just return a pointer
 to the new object.

 Something along the lines of:

 class Window
 {
 static Window opConstruct(void* ptr)
 {
 // Assume ptr is already correctly sized and filled
 Window result = cast(Window)ptr;
 result.__ctor();
 return return result;
 }
 }

 It seems like overloading new() *almost* does this, but not
 quite: It only lets you allocate the memory, not call the
 constructor yourself.

 This would be useful, because some objects can have external
 constructors (notably when interfacing with C/C++, such as when
 using CreateWindow() in Windows), and you *cannot* call these
 constructors inside the object's "constructor" (initializer) due
 to re-entrancy issues.

You can have a look at my Orange library: https://github.com/jacob-carlborg/orange/blob/master/orange/util/Reflection.d#L460 It's basically what TypeInfo_Class.create does but it doesn't call the constructor and works for LDC as well. https://github.com/D-Programming-Language/druntime/blob/master/src/object_.d#L878 -- /Jacob Carlborg
May 06 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-05-07 18:01, Mehrdad wrote:
 On Monday, 7 May 2012 at 09:18:11 UTC, David Nadlinger wrote:
 Doing it without a separate factory function (and maybe disabling new
 along with it by protecting the constructor) is not possible in D.

Okay that answers my question then.

No, have a look at this example: http://pastebin.com/UV5R82dg A bit of a hack. An other option would to use a separate public method that acts as a constructor. -- /Jacob Carlborg
May 07 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-05-07 11:18, David Nadlinger wrote:
 On Monday, 7 May 2012 at 07:28:18 UTC, Mehrdad wrote:
 Is this something that actually modifies the 'new' operator, or is it
 just a separate factory function that my code would need to switch to
 using?

Doing it without a separate factory function (and maybe disabling new along with it by protecting the constructor) is not possible in D. However, I don't quite see what it would gain you in the first place – besides potentially screwing up the semantics users expect from new… David

http://pastebin.com/UV5R82dg A bit of a hack. An other option would to use a separate public method that acts as a constructor. -- /Jacob Carlborg
May 07 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-05-07 09:28, Mehrdad wrote:

 Is this something that actually modifies the 'new' operator, or is it
 just a separate factory function that my code would need to switch to
 using?

This does not modify the new-operator. "_d_newclass" is actually the runtime function that is called by the compiler when it sees "new" in the code. It would be a separate factory function. As far as I know it's not possible to _not_ call the constructor when using new. -- /Jacob Carlborg
May 07 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-05-07 21:09, Mehrdad wrote:
 Oh, and ditto with the destructor: I need to be able to call the
 destructor manually, because the C does that inside a callback on my
 behalf.

About the destructor, have a look at how "clear" is implemented, it's supposed to replace "delete". Don't remember where it's defined. -- /Jacob Carlborg
May 07 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Monday, 7 May 2012 at 06:51:43 UTC, Jacob Carlborg wrote:
 You can have a look at my Orange library:

 https://github.com/jacob-carlborg/orange/blob/master/orange/util/Reflection.d#L460

 It's basically what TypeInfo_Class.create does but it doesn't 
 call the constructor and works for LDC as well.

 https://github.com/D-Programming-Language/druntime/blob/master/src/object_.d#L878

Thanks for the reply. Is this something that actually modifies the 'new' operator, or is it just a separate factory function that my code would need to switch to using?
May 07 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Monday, 7 May 2012 at 07:28:18 UTC, Mehrdad wrote:
 Is this something that actually modifies the 'new' operator, or 
 is it just a separate factory function that my code would need 
 to switch to using?

Doing it without a separate factory function (and maybe disabling new along with it by protecting the constructor) is not possible in D. However, I don't quite see what it would gain you in the first place – besides potentially screwing up the semantics users expect from new… David
May 07 2012
prev sibling next sibling parent "Era Scarecrow" <rtcvb32 yahoo.com> writes:
On Monday, 7 May 2012 at 09:18:11 UTC, David Nadlinger wrote:
 On Monday, 7 May 2012 at 07:28:18 UTC, Mehrdad wrote:
 Is this something that actually modifies the 'new' operator,  
 or is it just a separate factory function that my code would  
 need to switch to using?

Doing it without a separate factory function (and maybe disabling new along with it by protecting the constructor) is not possible in D. However, I don't quite see what it would gain you in the first place – besides potentially screwing up the semantics users expect from new…

What is your objective? What are you trying to achieve? I keep getting the impression of you using a object factory and a static function to create your objects, which would give you more optional behavior but not using new directly. class X { static X makeX() { X x; //make X or OOP descendant and return by whatever rules you need return x; } } Too much control is worse than not enough control. When I was testing out C++11 and getting my hands dirty, bugs were easily introduced where if you had to control certain gritty details, all details had to be controlled for it to work. If you don't have to control it, go around it to a simpler although slightly longer solution.
May 07 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Monday, 7 May 2012 at 10:15:56 UTC, Era Scarecrow wrote:
 
  What is your objective? What are you trying to achieve?

Did you read my first post? I already explained what this would be used for. Sure, you can do it with factories, but you can't factory-ize "delete", can you?
May 07 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Monday, 7 May 2012 at 09:18:11 UTC, David Nadlinger wrote:
 
 Doing it without a separate factory function (and maybe 
 disabling new along with it by protecting the constructor) is 
 not possible in D.

Okay that answers my question then.
 However, I don't quite see what it would gain you in the first 
 place – besides potentially screwing up the semantics users 
 expect from new…

It's a similar thing as when you override new's memory allocation part... yes, it can screw up the semantics, but it's assumed you know what you're doing...
May 07 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 07 May 2012 11:57:22 -0400, Mehrdad <wfunction hotmail.com> wrote:

 On Monday, 7 May 2012 at 10:15:56 UTC, Era Scarecrow wrote:
   What is your objective? What are you trying to achieve?

Did you read my first post? I already explained what this would be used for. Sure, you can do it with factories, but you can't factory-ize "delete", can you?

Not really, but then again, if you are not placing the class into the GC heap, who cares? You have to manually delete anyways, just use your specialized 'delete' function instead of delete. -Steve
May 07 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Monday, 7 May 2012 at 17:04:08 UTC, Steven Schveighoffer wrote:
 Not really, but then again, if you are not placing the class 
 into the GC heap, who cares?  You have to manually delete 
 anyways, just use your specialized 'delete' function instead of 
 delete.

 -Steve

No, I *am* placing it on the heap. I'm just asking if I can call the constructor manually, because (like I wrote in my first post...) sometimes the C code you're interoperating with takes control away from you, and just calls a callback on your behalf when constructing the object. (Yes, I realize there are different solutions to this problem. They're just not as elegant.)
May 07 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
Oh, and ditto with the destructor: I need to be able to call the 
destructor manually, because the C does that inside a callback on 
my behalf.

On Monday, 7 May 2012 at 19:08:18 UTC, Mehrdad wrote:
 No, I *am* placing it on the heap.

 I'm just asking if I can call the constructor manually, because
 (like I wrote in my first post...) sometimes the C code you're
 interoperating with takes control away from you, and just calls 
 a
 callback on your behalf when constructing the object.

 (Yes, I realize there are different solutions to this problem.
 They're just not as elegant.)

May 07 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 07 May 2012 15:08:16 -0400, Mehrdad <wfunction hotmail.com> wrote:

 On Monday, 7 May 2012 at 17:04:08 UTC, Steven Schveighoffer wrote:
 Not really, but then again, if you are not placing the class into the  
 GC heap, who cares?  You have to manually delete anyways, just use your  
 specialized 'delete' function instead of delete.

 -Steve

No, I *am* placing it on the heap.

You hadn't made that clear. In your first post, I was assuming your ptr came from some non-GC allocated space, which is why you wanted the ability to intercept it.
 I'm just asking if I can call the constructor manually, because
 (like I wrote in my first post...) sometimes the C code you're
 interoperating with takes control away from you, and just calls a
 callback on your behalf when constructing the object.

I wasn't sure, but I just tried it out: import std.stdio; extern(C) void *_d_newclass(TypeInfo t); // this is defined in rt/lifetime.d I cheated and used this, because I didn't want to have to type everything that was in it :) class C { int x; this(int x){this.x = x;} } void main() { C c = cast(C)_d_newclass(typeid(C)); c.__ctor(1); writeln(c.x); // outputs 1 } Seems to work -Steve
May 07 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 07 May 2012 15:09:34 -0400, Mehrdad <wfunction hotmail.com> wrote:

 Oh, and ditto with the destructor: I need to be able to call the  
 destructor manually, because the C does that inside a callback on my  
 behalf.

You definitely can do this. I think it's just __dtor. But I'm not sure if that calls the whole chain. rt_finalize, the function that actually calls the dtors calls each dtor in the chain individually. You can see how it works here: https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d#L1161 However, if C is calling your dtor, I'd highly recommend *not* using GC memory for your class data, you can std.conv.emplace it in C-malloced memory. If it has any references to GC data, use GC.addRoot to make sure that data isn't accidentally collected, and use GC.removeRoot before destruction. -Steve
May 07 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Monday, 7 May 2012 at 19:39:04 UTC, Steven Schveighoffer wrote:
 I'm just asking if I can call the constructor manually, because
 (like I wrote in my first post...) sometimes the C code you're
 interoperating with takes control away from you, and just 
 calls a
 callback on your behalf when constructing the object.

I wasn't sure, but I just tried it out: import std.stdio; extern(C) void *_d_newclass(TypeInfo t); class C { int x; this(int x){this.x = x;} } void main() { C c = cast(C)_d_newclass(typeid(C)); c.__ctor(1); writeln(c.x); // outputs 1 } Seems to work -Steve

Nonono :( you still missed what I was saying. Unless you're suggesting I replace _d_newclass, but that isn't type-specific (and I certainly don't want to replace it globally). Here's another attempt at the explanation: I definitely CAN make a helper method to do this for me. It's the whole factory pattern, etc. The problems are that: (1) The user wouldn't be able to say "new Window()" anymore (I already explained why) (2) The object couldn't be garbage collected. Regarding #2, in case it doesn't make sense why: It's because the C code takes control *AWAY* from you when you tell it to destroy the object. In my case, DestroyWindow(HWND) calls WndProc(WM_DESTROY,..), which is a member function. I CANNOT call DestroyWindow() in the finalizer, because then WndProc would be called on a *derived* class during cleanup. (It's the *same* issue as with the constructor.) So I'd have to do this manually, which defeats the whole point of making the object garbage-collectible in the first place. What I'm *want* to be able to do is, basically, to specify that I have a static method that will take care of finalizing an object. (Something like: void finalize(Window o)) Then, when the object is being finalized, the garbage collector would NOT call the object's finalizer directly. Instead, it would call my STATIC method to do the rest of the cleanup. The STATIC destruction method would call DestroyWindow() on the handle, and DestroyWindow() would send the notification to the window through a modified WndProc() (which I can always redirect, to make it NOT be a member function during the following phase). It would pass in a context parameter -- which would probably be the Window object itself -- to my (redirected) WndProc. The WndProc() would THEN call the Window's finalizer manually (and tell the GC that the object is done being finalized, so it can be collected). I can't think of any "nice" way around this. Either the HWND would have to be managed manually (in which case, that defeats the purpose of using the GC to ensure its destruction along with the object), or I would need an extra indirection in Window (which REALLY overcomplicates the design, and introduces lots of inheritance/template usage issues). The thing is, I think this doesn't need any compiler support either -- just a change in druntime. (I could be wrong though, since it might involve modifying TypeInfo_Class, I'm not sure.) Do you (or others) reckon a pull request to modify _d_newclass and _d_delclass so that they would call a custom static "constructor" and "destructor" for a class (if it specifies this should be the case) might be accepted? If there's the possibility then I might try hacking around with it... I can already see there being issues with inheritance, but I think it would be fixable in some cases, and disallowable in others. (Would obviously need to try it and see though.)
May 07 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 07 May 2012 16:09:06 -0400, Mehrdad <wfunction hotmail.com> wrote:

 On Monday, 7 May 2012 at 19:39:04 UTC, Steven Schveighoffer wrote:
 I'm just asking if I can call the constructor manually, because
 (like I wrote in my first post...) sometimes the C code you're
 interoperating with takes control away from you, and just calls a
 callback on your behalf when constructing the object.

I wasn't sure, but I just tried it out: import std.stdio; extern(C) void *_d_newclass(TypeInfo t); class C { int x; this(int x){this.x = x;} } void main() { C c = cast(C)_d_newclass(typeid(C)); c.__ctor(1); writeln(c.x); // outputs 1 } Seems to work -Steve

Nonono :( you still missed what I was saying. Unless you're suggesting I replace _d_newclass, but that isn't type-specific (and I certainly don't want to replace it globally).

All _d_newclass does is allocate memory for the object and initialize it to it's initial state (i.e. if an int member is initialized to 5, it does this). It does not call the constructor. So no, I was assuming you'd either re-use it, or implement some other allocation means.
 Here's another attempt at the explanation:

 I definitely CAN make a helper method to do this for me. It's the whole  
 factory pattern, etc.

 The problems are that:
 (1) The user wouldn't be able to say "new Window()" anymore (I already  
 explained why)

Right. new === allocate memory on the GC heap (via _d_newclass) and call the constructor. If you don't want that you cannot use new.
 (2) The object couldn't be garbage collected.

Then you definitely don't want GC allocated memory.
 Regarding #2, in case it doesn't make sense why:
 It's because the C code takes control *AWAY* from you when you tell it  
 to destroy the object.
 In my case, DestroyWindow(HWND) calls WndProc(WM_DESTROY,..), which is a  
 member function.

So it should not call GC.malloc to create the memory, use C's malloc, and GC.addRoot.
 I CANNOT call DestroyWindow() in the finalizer, because then WndProc  
 would be called on a *derived* class during cleanup. (It's the *same*  
 issue as with the constructor.) So I'd have to do this manually, which  
 defeats the whole point of making the object garbage-collectible in the  
 first place.


 What I'm  *want* to be able to do is, basically, to specify that I have  
 a static method that will take care of finalizing an object. (Something  
 like: void finalize(Window o))

What I think you want is both an allocator/initializer and a destructor. Kind of like malloc and free. The two are going to be tied together, so you should always have to call the correct destructor for an object allocated with the initializer.
 Then, when the object is being finalized, the garbage collector would  
 NOT call the object's finalizer directly. Instead, it would call my  
 STATIC method to do the rest of the cleanup.

 The STATIC destruction method would call DestroyWindow() on the handle,  
 and DestroyWindow() would send the notification to the window through a  
 modified WndProc() (which I can always redirect, to make it NOT be a  
 member function during the following phase).

 It would pass in a context parameter -- which would probably be the  
 Window object itself -- to my (redirected) WndProc.
 The WndProc() would THEN call the Window's finalizer manually (and tell  
 the GC that the object is done being finalized, so it can be collected).

I think avoiding the GC completely is a much better idea. All you need to be concerned about is references from your object into the GC heap (i.e. use addRoot/removeRoot).
 I can't think of any "nice" way around this. Either the HWND would have  
 to be managed manually (in which case, that defeats the purpose of using  
 the GC to ensure its destruction along with the object), or I would need  
 an extra indirection in Window (which REALLY overcomplicates the design,  
 and introduces lots of inheritance/template usage issues).

I guess I don't really understand that. Who is responsible for cleaning up your class instance? The way I was understanding your description, I thought it was the C window runtime calling a callback you provide to it. Why do you need to have the GC clean it up?
 Do you (or others) reckon a pull request to modify _d_newclass and  
 _d_delclass so that they would call a custom static "constructor" and  
 "destructor" for a class (if it specifies this should be the case) might  
 be accepted?

_d_newclass does *not* call ctors, the compiler does that when you say "new" Otherwise, _d_newclass it would have to handle passing through all the parameters to the ctor. It does roughly what I showed you in my quick example. -Steve
May 07 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Monday, 7 May 2012 at 21:07:15 UTC, Steven Schveighoffer wrote:
 I guess I don't really understand that.  Who is responsible for 
 cleaning up your class instance?  The way I was understanding 
 your description, I thought it was the C window runtime calling 
 a callback you provide to it.  Why do you need to have the GC 
 clean it up?

Ah, I see why that's confusing. Here's a (hopefully better) explanation: Just as with any other object that represents an outside resource (e.g. a File/Stream/whatever), the lifetime of the unmanaged object should always follow the lifetime of the managed object. In other words, this means that the creation of a Window object MUST be associated with the system call CreateWindow() (which in turns calls the window dispatcher function, WndProc, with the message WM_CREATE). And, more importantly, this means that if the GC collects the Window object, then DestroyWindow() MUST be called on the kernel object, so that the window handle doesn't get leaked. Just as with any other resource. The trouble is that, as-is, this behavior is NOT implementable with a simple Window class whose constructor calls CreateWindow() and whose destructor calls DestroyWindow(). Why? Because if you were to do that in the constructor or destructor, the system would call back your WndProc() function, which is a *virtual* function meant to be overridden in the derived classes (so that they can handle events, such as the creation/destruction of the window, or the calculation of the window size, etc. properly). That would mean your WndProc() in the derived instance would be called *before* the constructor of the derived instance is called, which is obviously not what you want. Ditto with the destructor -- if you were to call DestroyWindow() in the ~Window(), then it would call back WndProc with the message WM_DESTROY in the derived class. The only solution I see is to somehow call DestroyWindow() *BEFORE* you call the destructor, and call the destructor manually when the WM_DESTROY message is received. Ditto with the constructor: you need to somehow call CreateWindow() *BEFORE* you call the constructor, so that when you receive the WM_CREATE message, you can call the constructor manually. Only by hijacking the construction and destruction call can you guarantee that the construction/destruction happens in an orderly fashion, i.e. that the kernel object lifetime tracks the user object lifetime properly. Otherwise you either miss getting some notifications at critical points (which results in incorrect code, which some people may or may not care about), or you risk getting a handle leak (also obviously bad). Or you risk making the design pattern pretty horrific, kind of like how C# has a "NativeWindow" inside of the Control class, and they both have creation parameters, and they both register themselves ("park" themselves) globally on a static/shared field, and run into all sorts of ugly issues that you shouldn't need to run into. (If you look at the code and understand what they're doing, you'll see what I mean when I say it's ugly...) Summary: Yes, I need the GC so I can manage the HWND lifetime properly, i.e. so it tracks the lifetime of the Window object (otherwise you can easily leak a handle). But in order to do this, I also need to be able to call the constructor/destructor manually, because the C code does this through a callback, which isn't possible when your object is being GC'd, due to virtual method re-entrancy issues with finalization. Does that make sense? Is any part of it still unclear?
May 07 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 07 May 2012 19:00:22 -0400, Mehrdad <wfunction hotmail.com> wrote:

 On Monday, 7 May 2012 at 21:07:15 UTC, Steven Schveighoffer wrote:
 I guess I don't really understand that.  Who is responsible for  
 cleaning up your class instance?  The way I was understanding your  
 description, I thought it was the C window runtime calling a callback  
 you provide to it.  Why do you need to have the GC clean it up?

Ah, I see why that's confusing. Here's a (hopefully better) explanation: Just as with any other object that represents an outside resource (e.g. a File/Stream/whatever), the lifetime of the unmanaged object should always follow the lifetime of the managed object. In other words, this means that the creation of a Window object MUST be associated with the system call CreateWindow() (which in turns calls the window dispatcher function, WndProc, with the message WM_CREATE). And, more importantly, this means that if the GC collects the Window object, then DestroyWindow() MUST be called on the kernel object, so that the window handle doesn't get leaked. Just as with any other resource. The trouble is that, as-is, this behavior is NOT implementable with a simple Window class whose constructor calls CreateWindow() and whose destructor calls DestroyWindow(). Why? Because if you were to do that in the constructor or destructor, the system would call back your WndProc() function, which is a *virtual* function meant to be overridden in the derived classes (so that they can handle events, such as the creation/destruction of the window, or the calculation of the window size, etc. properly). That would mean your WndProc() in the derived instance would be called *before* the constructor of the derived instance is called, which is obviously not what you want.

OK, I understand what you are saying now. What about using NVI? class Window { protected void processMessage_impl(int message) // virtual call {} final public void processMessage(int message) { if(message == WM_CREATE) { // handle specially } else if(message == WM_DELETE) { // handle specially } else { processMessage_impl(int message); } } private HWND window; this() { window = CreateWindow(&processMessage); // or whatever mechanism, you get the idea } ~this() { DestroyWindow(window); } } -Steve
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
 OK, I understand what you are saying now.

 What about using NVI?

 class Window
 {
   protected void processMessage_impl(int message) // virtual 
 call
   {}
   final public void processMessage(int message)
   {
     if(message == WM_CREATE)
     {
        // handle specially
     }
     else if(message == WM_DELETE)
     {
        // handle specially
     }
     else
     {
         processMessage_impl(int message);
     }
   }
   private HWND window;
   this()
   {
     window = CreateWindow(&processMessage); // or whatever 
 mechanism, you get the idea
   }
   ~this()
   {
     DestroyWindow(window);
   }
 }

 -Steve

The trouble is that if you "handle these specially", then your subclasses won't.... But your subclasses MUST still be able to handle these messages, because they might need to do something special when the messages are sent. (For example, you might need to calculate the size of the window when WM_CREATE or WM_NCCREATE is sent. Or something else... there are a ton of situations that can happen -- such as MDI window creation, etc. -- that don't happen too often, but happen often enough that you simply can't assume you can get by without allowing them to handle the messages.)
May 11 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 11 May 2012 09:33:54 -0400, Mehrdad <wfunction hotmail.com> wrote:

 OK, I understand what you are saying now.

 What about using NVI?

 class Window
 {
   protected void processMessage_impl(int message) // virtual call
   {}
   final public void processMessage(int message)
   {
     if(message == WM_CREATE)
     {
        // handle specially
     }
     else if(message == WM_DELETE)
     {
        // handle specially
     }
     else
     {
         processMessage_impl(int message);
     }
   }
   private HWND window;
   this()
   {
     window = CreateWindow(&processMessage); // or whatever mechanism,  
 you get the idea
   }
   ~this()
   {
     DestroyWindow(window);
   }
 }

 -Steve

The trouble is that if you "handle these specially", then your subclasses won't.... But your subclasses MUST still be able to handle these messages, because they might need to do something special when the messages are sent. (For example, you might need to calculate the size of the window when WM_CREATE or WM_NCCREATE is sent.

I'm probably not getting the entire picture here, but I assume from your description that CreateWindow directly calls your WndProc. If that is the case, isn't it guaranteed that after the base ctor runs the class has received the WM_CREATE message? I mean, the only issue happens when you are not quite through the ctor chain, no?
 Or something else... there are a ton of situations that can happen --  
 such as MDI window creation, etc. -- that don't happen too often, but  
 happen often enough that you simply can't assume you can get by without  
 allowing them to handle the messages.)

You can use another mechanism to decide. for instance: class Window private bool inCreateWindow = false; ... final public void processMessage(int message) { if(inCreateWindow && message == WM_CREATE) { // handle specially } ... } this() { inCreateWindow = true; window = CreateWindow(&processMessage); inCreateWindow = false; // all WM_CREATE messages will now go through normal mechanism. } } -Steve
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
 I'm probably not getting the entire picture here, but I assume 
 from your description that CreateWindow directly calls your 
 WndProc.  If that is the case, isn't it guaranteed that after 
 the base ctor runs the class has received the WM_CREATE 
 message?  I mean, the only issue happens when you are not quite 
 through the ctor chain, no?

Right, what I'm saying is that it's the *subclass* who needs the notification more, than anyone else (although, for other reasons, the base class needs it as well). The whole point is to get the messages to the *subclasses* properly...
 Or something else... there are a ton of situations that can 
 happen -- such as MDI window creation, etc. -- that don't 
 happen too often, but happen often enough that you simply 
 can't assume you can get by without allowing them to handle 
 the messages.)

You can use another mechanism to decide. for instance: class Window private bool inCreateWindow = false; ... final public void processMessage(int message) { if(inCreateWindow && message == WM_CREATE) { // handle specially } ... } this() { inCreateWindow = true; window = CreateWindow(&processMessage); inCreateWindow = false; // all WM_CREATE messages will now go through normal mechanism. } } -Steve

May 11 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 11 May 2012 10:04:00 -0400, Mehrdad <wfunction hotmail.com> wrote:

 I'm probably not getting the entire picture here, but I assume from  
 your description that CreateWindow directly calls your WndProc.  If  
 that is the case, isn't it guaranteed that after the base ctor runs the  
 class has received the WM_CREATE message?  I mean, the only issue  
 happens when you are not quite through the ctor chain, no?

Right, what I'm saying is that it's the *subclass* who needs the notification more, than anyone else (although, for other reasons, the base class needs it as well). The whole point is to get the messages to the *subclasses* properly...

Yeah, but given that the subclass is calling the base constructor, and the base constructor does not return until WM_CREATE is received, can't the subclass constructor pretend it received the message? -Steve
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 14:17:04 UTC, Steven Schveighoffer 
wrote:
 Yeah, but given that the subclass is calling the base 
 constructor, and the base constructor does not return until 
 WM_CREATE is received, can't the subclass constructor pretend 
 it received the message?

 -Steve

"pretend"? No, because the window handle doesn't even EXIST until WM_CREATE passes it to the window instance! (Sorry I guess I didn't mention that, but it was kind of implicit in the fact that messages are passed *before* CreateWindow() returns.) Yes, CreateWindow() also returns a copy of the handle, but stuff happens *before* the handle is returned, and in order for the class to properly handle it, the handle is passed along with WM_CREATE (and, in fact, with another message called WM_NCCREATE, but we can ignore that for now). The subclass has NO access to the window handle whatsoever before the message comes, so no, it can't "pretend" to have received the handle because that wouldn't be of any use.
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 14:20:47 UTC, Mehrdad wrote:
 On Friday, 11 May 2012 at 14:17:04 UTC, Steven Schveighoffer 
 wrote:
 Yeah, but given that the subclass is calling the base 
 constructor, and the base constructor does not return until 
 WM_CREATE is received, can't the subclass constructor pretend 
 it received the message?

 -Steve

"pretend"? The subclass has NO access to the window handle whatsoever before the message comes, so no, it can't "pretend" to have received the handle because that wouldn't be of any use.

Or did you mean *after* the base class constructor is called? If you meant that: no, that's pretty useless because the whole point of receiving a message is to respond to it appropriately! If you miss the actual notification you can't time-travel back and say, "just kidding, I actually wanted to do X-Y-Z when the message came, so can we redo this whole window creation thing?" :P That's exactly what I was saying when I said that you can't afford to miss a message and hope that you can just change stuff later...
May 11 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 11 May 2012 10:31:26 -0400, Mehrdad <wfunction hotmail.com> wrote:

 On Friday, 11 May 2012 at 14:20:47 UTC, Mehrdad wrote:
 On Friday, 11 May 2012 at 14:17:04 UTC, Steven Schveighoffer wrote:
 Yeah, but given that the subclass is calling the base constructor, and  
 the base constructor does not return until WM_CREATE is received,  
 can't the subclass constructor pretend it received the message?

 -Steve

"pretend"? The subclass has NO access to the window handle whatsoever before the message comes, so no, it can't "pretend" to have received the handle because that wouldn't be of any use.

Or did you mean *after* the base class constructor is called? If you meant that: no, that's pretty useless because the whole point of receiving a message is to respond to it appropriately! If you miss the actual notification you can't time-travel back and say, "just kidding, I actually wanted to do X-Y-Z when the message came, so can we redo this whole window creation thing?" :P That's exactly what I was saying when I said that you can't afford to miss a message and hope that you can just change stuff later...

Yes I did mean that. I'm thinking about it, one thing you did not mention, but almost certainly is the case (it usually is with GUI toolkits) is that the WndProc is called in a different thread or context than the constructor. This means, there may be functions that you can call in WndProc that you cannot call in the ctor. So even though CreateWindow returning means WM_CREATE must have been received, the context you need to handle WM_CREATE is gone. Is that true? I'll wait for an answer before thinking more about this. It feels imminently solvable... -Steve
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 15:23:10 UTC, Steven Schveighoffer 
wrote:
 Yes I did mean that.

 I'm thinking about it, one thing you did not mention, but 
 almost certainly is the case (it usually is with GUI toolkits) 
 is that the WndProc is called in a different thread or context 
 than the constructor.

It's in the same exact thread as the caller of CreateWindow in Win32 (not sure what you mean by "context" here, but AFAIK nothing is changed about the thread... nothing fiber-like or anything like that going on). I'm not familiar with other OSes though.
 This means, there may be functions that you can call in WndProc 
 that you cannot call in the ctor.

 So even though CreateWindow returning means WM_CREATE must have 
 been received, the context you need to handle WM_CREATE is 
 gone.  Is that true?

Again, not sure what you mean by "context", but there is nothing changed about the thread here. You could nest the creation of 10 windows down this chain of WM_CREATE's (in fact, that's one of its purposes) and it's all gonna happen for the same thread, in the same "context" (assuming that's referring to the thread context). Furthermore, the system waits for your response, because if you return -1, the window is not created, and an error is returned to the caller. (Yet another reason why you need to be able to handle the message when it's sent, not a year later.)
 I'll wait for an answer before thinking more about this.  It 
 feels imminently solvable...

Okay. :P Though I've thought about it for a while and I'm getting more and more convinced there isn't a good solution for this without the ability to do custom construction...
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 15:36:37 UTC, Mehrdad wrote:
 It's in the same exact thread as the caller of CreateWindow in 
 Win32

Minor correction: that's under the assumption that the thread that registered the window class (with RegisterClass()) is the same thread creating the window, which is the case most of the time. But if it's one process instantiating the window of a different process (which happens sometimes), or if it's one thread instantiating the window of a different thread (which happens more rarely), that's obviously not the case...
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 15:41:02 UTC, Mehrdad wrote:
 On Friday, 11 May 2012 at 15:36:37 UTC, Mehrdad wrote:
 It's in the same exact thread as the caller of CreateWindow in 
 Win32

Minor correction: that's under the assumption that the thread that registered the window class (with RegisterClass()) is the same thread creating the window, which is the case most of the time. But if it's one process instantiating the window of a different process (which happens sometimes), or if it's one thread instantiating the window of a different thread (which happens more rarely), that's obviously not the case...

Never mind, I actually messed up the last part; it's the same thread throughout: http://www.oopweb.com/Assembly/Documents/Win32ASM/Volume/winmsg.htm#windowthread I just got this confused because if you happen to use SendMessage() to send the message, THEN the rule I mentioned applies. But here, the system calls the window procedure directly, and as the link says, only the current ever calls the window procedure.
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
Since I kinda failed at explaining it, here's a better link, MSDN 
itself:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms644950.aspx

Note what it says happens when you call SendMessage():

"If the specified window was created by the calling thread, the 
window procedure is called immediately as a subroutine. If the 
specified window was created by a different thread, the system 
switches to that thread and calls the appropriate window 
procedure. Messages sent between threads are processed only when 
the receiving thread executes message retrieval code. The sending 
thread is blocked until the receiving thread processes the 
message."

So, in other words, the thread of RegisterClass() doesn't have 
much to do with anything so far as the window procedure is 
concerned -- the window procedure is always executed in the same 
thread that created the window. (We're not using SendMessage() 
here, but the rule regarding who can call the window procedure is 
the same.)
May 11 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-05-06 21:55, Mehrdad wrote:
 Is this possible in D2?

 i.e. I'm wondering if there is a way to do the object
 construction yourself, which would allow you to call the object's
 "constructor" (initializer) manually, and just return a pointer
 to the new object.

 Something along the lines of:

 class Window
 {
 static Window opConstruct(void* ptr)
 {
 // Assume ptr is already correctly sized and filled
 Window result = cast(Window)ptr;
 result.__ctor();
 return return result;
 }
 }

 It seems like overloading new() *almost* does this, but not
 quite: It only lets you allocate the memory, not call the
 constructor yourself.

 This would be useful, because some objects can have external
 constructors (notably when interfacing with C/C++, such as when
 using CreateWindow() in Windows), and you *cannot* call these
 constructors inside the object's "constructor" (initializer) due
 to re-entrancy issues.

Don't know if it helps but, have a look the DWT sources: https://github.com/d-widget-toolkit/org.eclipse.swt.win32.win32.x86/tree/master/src/org/eclipse/swt should probably be in the internal folder, widgets/Widget or widgets/Shell. -- /Jacob Carlborg
May 11 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-05-12 20:30, Mehrdad wrote:

 Yes, that's not a WinForms thing -- when you close a window, it's
 trivial to have DestroyWindow() get called too.

 The trouble is that you can't rely on this to avoid handle leaks -- for
 example, message-only windows are invisible, so their handles can get
 leaked and they can never be closed.

A DWT Hello World application looks like this: void main () { auto display = new Display; auto shell = new Shell(display); shell.open(); while (!shell.isDisposed) if (!display.readAndDispatch()) display.sleep(); display.dispose(); } You always call "display.dispose" at the end of the main function. Since "dispose" will dispose all of the receiver's children and "display" is the top level widget, everything will be disposed when the application exits. -- /Jacob Carlborg
May 14 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-05-14 10:10, Mehrdad wrote:
 On Monday, 14 May 2012 at 07:26:27 UTC, Jacob Carlborg wrote:
 You always call "display.dispose" at the end of the main function.
 Since "dispose" will dispose all of the receiver's children and
 "display" is the top level widget, everything will be disposed when
 the application exits.

*sigh* I just spent a few posts explaining why you need to clean things up in the destructor, and then I get a reply telling me to just manage resources manually, screw automatic garbage collection. >_<

No, I'm telling you how SWT/DWT works. How "dispose" works in DWT is _not_ the same as doing managing memory manually. -- /Jacob Carlborg
May 14 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 22:28:55 UTC, Jacob Carlborg wrote:
 On 2012-05-06 21:55, Mehrdad wrote:
 Is this possible in D2?

 i.e. I'm wondering if there is a way to do the object
 construction yourself, which would allow you to call the 
 object's
 "constructor" (initializer) manually, and just return a pointer
 to the new object.

 Something along the lines of:

 class Window
 {
 static Window opConstruct(void* ptr)
 {
 // Assume ptr is already correctly sized and filled
 Window result = cast(Window)ptr;
 result.__ctor();
 return return result;
 }
 }

 It seems like overloading new() *almost* does this, but not
 quite: It only lets you allocate the memory, not call the
 constructor yourself.

 This would be useful, because some objects can have external
 constructors (notably when interfacing with C/C++, such as when
 using CreateWindow() in Windows), and you *cannot* call these
 constructors inside the object's "constructor" (initializer) 
 due
 to re-entrancy issues.

Don't know if it helps but, have a look the DWT sources: https://github.com/d-widget-toolkit/org.eclipse.swt.win32.win32.x86/tree/master/src/org/eclipse/swt should probably be in the internal folder, widgets/Widget or widgets/Shell.

Thanks for the link. It seems like it's on Control.d... Yup, they do what C# does with the constructor: they put make a *separate* function, createHandle(), used to create the control. And they simply *don't* tie the destructor to DestroyWindow(); instead, they just assume the user will call dispose(). So in other words, they just ignored the entire problem with the lifetimes, and hoped ("required"?) that the user will call dispose(). Not something I'd want to do, since (even according to .NET's philosophy) a handle leak must NEVER occur, as long as the program has control, even if the user doesn't dispose the object. The closing of the handle can of course be nondeterministic due to the GC, but it must be eventually cleaned up when the object is GC'd. Any ideas if this would be easy/hard to add to DMD/Phobos?
May 11 2012
prev sibling next sibling parent "John Chapman" <johnch_atms hotmail.com> writes:
 Yup, they do what C# does with the constructor: they put make a 
 *separate* function, createHandle(), used to create the control.

 And they simply *don't* tie the destructor to DestroyWindow(); 
 instead, they just assume the user will call dispose().>
 So in other words, they just ignored the entire problem with 
 the lifetimes, and hoped ("required"?) that the user will call 
 dispose().

Actually, in WinForms, closing the application's main Form triggers its Dispose method, which disposes of child Controls too.
May 12 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Saturday, 12 May 2012 at 15:57:37 UTC, John Chapman wrote:
 Yup, they do what C# does with the constructor: they put make 
 a *separate* function, createHandle(), used to create the 
 control.

 And they simply *don't* tie the destructor to DestroyWindow(); 
 instead, they just assume the user will call dispose().>
 So in other words, they just ignored the entire problem with 
 the lifetimes, and hoped ("required"?) that the user will call 
 dispose().

Actually, in WinForms, closing the application's main Form triggers its Dispose method, which disposes of child Controls too.

Yes, that's not a WinForms thing -- when you close a window, it's trivial to have DestroyWindow() get called too. The trouble is that you can't rely on this to avoid handle leaks -- for example, message-only windows are invisible, so their handles can get leaked and they can never be closed.
May 12 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Monday, 14 May 2012 at 07:26:27 UTC, Jacob Carlborg wrote:
 You always call "display.dispose" at the end of the main 
 function. Since "dispose" will dispose all of the receiver's 
 children and "display" is the top level widget, everything will 
 be disposed when the application exits.

*sigh* I just spent a few posts explaining why you need to clean things up in the destructor, and then I get a reply telling me to just manage resources manually, screw automatic garbage collection. >_<
May 14 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Monday, 14 May 2012 at 13:25:11 UTC, Jacob Carlborg wrote:
 No, I'm telling you how SWT/DWT works. How "dispose" works in 
 DWT is _not_ the same as doing managing memory manually.

Memory? The entire issue is about a handle leak, not a memory leak...
May 14 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Friday, 11 May 2012 at 15:23:10 UTC, Steven Schveighoffer 
wrote:
 I'll wait for an answer before thinking more about this.  It 
 feels imminently solvable...

 -Steve

Did you come across any ideas? :)
May 31 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 31 May 2012 03:25:40 -0400, Mehrdad <wfunction hotmail.com> wrote:

 On Friday, 11 May 2012 at 15:23:10 UTC, Steven Schveighoffer wrote:
 I'll wait for an answer before thinking more about this.  It feels  
 imminently solvable...

 -Steve

Did you come across any ideas? :)

Sorry lost track of this. I'll think about it again. -Steve
May 31 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Thursday, 31 May 2012 at 10:58:51 UTC, Steven Schveighoffer 
wrote:
 On Thu, 31 May 2012 03:25:40 -0400, Mehrdad 
 <wfunction hotmail.com> wrote:

 On Friday, 11 May 2012 at 15:23:10 UTC, Steven Schveighoffer 
 wrote:
 I'll wait for an answer before thinking more about this.  It 
 feels imminently solvable...

 -Steve

Did you come across any ideas? :)

Sorry lost track of this. I'll think about it again. -Steve

o lol. ok. Do you think it'd be difficult to add an extra layer of indirection for calling the current "constructors"/finalizers? I feel like, if DMD would just look for a __construct and a __destroy static method instead of directly calling the constructor/finalizer, it'd all work out nicely...
May 31 2012
prev sibling parent "Mehrdad" <wfunction hotmail.com> writes:
I just added this:
http://d.puremagic.com/issues/show_bug.cgi?id=8177


I don't understand the DMD code well enough to implement this
myself (the identifiers are all Greek to me...), but I honestly
think implementing it should be relatively simple, since the
default implementations are trivial (and I don't think it
requires too much code to be changed in DMD).



If someone could implement it -- or perhaps guide me through
where I should look/how I could implement it myself -- I'd really
appreciate it. :) Thanks!
May 31 2012