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.

Oh, and add "custom destructors" to that question as well: static methods that call ~this() manually on the object.

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

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?

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

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.

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?

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...

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

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.)