No PlacementNew alternative

[sekkit]

The lib I imported into UnityNativeScripting conflicts with new operator when compiling in Windows(VC15)
BUT it compiles fine with Xcode.
So I need to bypass this placement new trick. Any idea would be great^^

	{
		MyGame::BaseBallScript* memory = Plugin::StoreWholeBaseBallScript(); 
		//MyGame::BallScript* thiz = new (memory) MyGame::BallScript(Plugin::InternalUse::Only, handle); 
		//return thiz->CppHandle;
		MyGame::BallScript* thiz = new (memory) MyGame::BallScript(Plugin::InternalUse::Only, handle);
		return 0;
	}

[sekkit]

namespace MyGame
{
	struct BaseBallScript : virtual MyGame::AbstractBaseBallScript
	{
		BaseBallScript(decltype(nullptr));
		BaseBallScript(Plugin::InternalUse, int32_t handle);
		BaseBallScript(const BaseBallScript& other);
		BaseBallScript(BaseBallScript&& other);
		virtual ~BaseBallScript();
		BaseBallScript& operator=(const BaseBallScript& other);
		BaseBallScript& operator=(decltype(nullptr));
		BaseBallScript& operator=(BaseBallScript&& other);
		bool operator==(const BaseBallScript& other) const;
		bool operator!=(const BaseBallScript& other) const;
		int32_t CppHandle;
		BaseBallScript();
		virtual void Update();

		void* operator new(size_t s, void* p) 
		{  
			return p;
		}  
		
		void operator delete(void* p)  
		{  
			
		}
	};
}

The issue seems to be gone after adding new delete operator overloading to the class instead of globally.
But I don't know whether to free void* p in delete or not...

[Jackson Dunstan]

I'm also using VC15 on Windows and have no such compiler error. Could it be due to some code you've added on the C++ side that conflicts with the project?

[sekkit]

I'm also using VC15 on Windows and have no such compiler error. Could it be due to some code you've added on the C++ side that conflicts with the project?

This issue is not reproducible in your original project.
When compiling together with PyBind11(C++ code)
Windows VS compiler complains about ::new symbol conflicts.

Changing operator new declaration from global to member function, the Error is gone, but I don't know whether should implement delete properly.(if not, compiler warning will prompt for delete pair decleration)

[Jackson Dunstan]

I'm glad to hear that it's not an issue with the project as-is, but sorry to hear that there's a conflict for the global new operator. I'll look into using member operators for new and delete instead of global ones to reduce such conflicts.

[sekkit]

I'm glad to hear that it's not an issue with the project as-is, but sorry to hear that there's a conflict for the global new operator. I'll look into using member operators for new and delete instead of global ones to reduce such conflicts.

Either I write as:

void operator delete(void* p)  
{ 		
}

//or 

void operator delete(void* p)  
{ 	
	::operator delete(p);
}

Works fine(no crash so far), strange.
I will email you my project later. thx.

[Jackson Dunstan]

Reopening issue since the enhancement (containing the scope of the new and delete operators) has not yet been completed.

[Jackson Dunstan]

7107c69 addresses this issue by removing the global placement new operator in favor of class-specific placement new and placement delete operators similar to what you did. To add them to your derived types (e.g. BallScript), add one of the following macro calls:

// Declarations of placement new and placement delete
// Put this inside the class definition
MY_GAME_BALL_SCRIPT_DEFAULT_CONTENTS_DECLARATION

// Definitions of placement new and placement delete
// Put this outside the class definition
MY_GAME_BALL_SCRIPT_DEFAULT_CONTENTS_DEFINITION

// Inline definitions of placement new and placement delete
// Put this inside the class definition
MY_GAME_BALL_SCRIPT_DEFAULT_CONTENTS

I've tested this on macOS with Xcode 10 and Windows 10 with Visual Studio 2017. Please let me know if this doesn't solve the issue for you or you run into any trouble with it.

[sekkit]

Hi, test it worked.
but

#define GAME_SCRIPT_BEHAVIOUR_DEFAULT_CONTENTS\
	void* operator new(size_t, void* p) noexcept \
	{ \
		return p; \
	} \
	void operator delete(void*, size_t) noexcept \
	{ \
	}

I guess name it GENERIC_DEFAULT_CONTENTS could save some duplicated definitions.

[Jackson Dunstan]

It's true that those are duplicated, as are GAME_SCRIPT_BEHAVIOUR_DEFAULT_CONTENTS_DECLARATION, but GAME_SCRIPT_BEHAVIOUR_DEFAULT_CONTENTS_DEFINITION is different as it includes the type name:

#define MY_GAME_BALL_SCRIPT_DEFAULT_CONTENTS_DEFINITION \
	void* BallScript::operator new(size_t, void* p) noexcept\
	{ \
		return p; \
	} \
	void BallScript::operator delete(void*, size_t) noexcept \
	{ \
	}

I opted to accept the minor amount of duplication for consistency's sake.

[sekkit]

ok, not big deal though.
I already merged your latest change, but the MonoBehaviour old implementation described as in https://jacksondunstan.com/articles/3992, is it possible to bring'em back?
coz i think it's kinda time saver to bypass the crash in another issue^_^

if u run my mail's DEMO, i think it's obvious.