[CORE] Fix copying of RefCountClass, RefCountValue

[xezon]

• Follow up for [GEN][ZH] Change reference counter implementation for StateMachine to avoid mismatch with Retail #1078

This change fixes the copying for RefCountClass, RefCountValue. Reference counter values cannot be copied. Thw wrong copy currently causes no bugs in the code.

[Mauller]

Should we allow the copy constructor at all in this instance? seems like it should be kept private.

The copy assignment is okay in this instance since we just return a reference to the original lilke you did.

[xezon]

I think it must be public because we still would want to be able to copy objects that use ref counters right? So the ref counter should not prevent us from copying. It would be up the user class to prevent copying.

[Mauller]

I would say that the copy constructor being private tells the user of the class that the counter should not be directly copied. It puts emphasis on the required functionality at the source and that copying is invalid.

IT also tells the user that the class inheriting or implementing the ref counter must explicitly create a new ref counter during a copy for the new object.

[xezon]

But it will prevent whole objects from copying that use these ref counters. This cannot be desirable.

[Mauller]

That would be the whole point, it requires the class using a ref counter to explicitly make a new reference counter. but setting the ref count to 1 when allowing a copy construction of the ref should not be so bad.

It just puts more required understanding on the person who is copying the ref counter object to understand that its implicitly resetting the reference count.

The way it is implemented should work fine, it just requires the user to fully understand the consequences of a copy.

[Mauller]

If the operator= was private then it means that the operator= of the user class would also be implictly private, right?

...

Oh in these instances i have been refering to the copy constructor, not the copy assignment.

[xezon]

Oh in these instances i have been refering to the copy constructor, not the copy assignment.

Ok. This leads to the same story though:

struct MyStruct
{
	int a = 0;
	RefCountValue<int> value;
};

inline void test()
{
	MyStruct str1;
	MyStruct str2(str1); // fails to compile
}

I think it should be up to MyStruct to decide whether copy construction or assignment is allowed.

[Mauller]

The thing that shouldn't be copied should prevent itself from being copied.

That is how i have always seen and done it, In this instance having the copy constructor set the reference on the copy to 1 it not so bad since it's quite a simple object and should be fine for what this class is doing.

But when the object is more complex the emphasis should be on the class that shoulnd't be copied, not the classes making use of it.

[xezon]

Ok. In this case defaulting the ref counter to 1 on copy is perfectly reasonable.

[Mauller]

Yeah, this is good to merge otherwise.