Skip to content

[CORE] Fix copying of RefCountClass, RefCountValue #1081

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
xezon merged 1 commit into from
Jun 21, 2025
Merged

[CORE] Fix copying of RefCountClass, RefCountValue #1081

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions Core/Libraries/Source/WWVegas/WWLib/refcount.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -123,6 +123,9 @@ class RefCountClass
#endif
}

/*
** The reference counter value cannot be copied.
*/
RefCountClass(const RefCountClass & ) :
NumRefs(1)
#ifndef NDEBUG
Expand All @@ -135,6 +138,8 @@ class RefCountClass
#endif
}

RefCountClass& operator=(const RefCountClass&) { return *this; }

/*
** Add_Ref, call this function if you are going to keep a pointer
** to this object.
Expand Down Expand Up @@ -280,6 +285,12 @@ class RefCountValue
WWASSERT(NumRefs == IntegerType(0));
}

/*
** The reference counter value cannot be copied.
*/
RefCountValue(const RefCountValue&) : NumRefs(1) {}

@Mauller Mauller Jun 20, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 xezon Jun 21, 2025

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Mauller Jun 21, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 xezon Jun 21, 2025

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@Mauller Mauller Jun 21, 2025 •
edited
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Mauller Jun 21, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 xezon Jun 21, 2025 •
edited
Loading

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Mauller Jun 21, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 xezon Jun 21, 2025

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@Mauller Mauller Jun 21, 2025

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this is good to merge otherwise.

RefCountValue& operator=(const RefCountValue&) { return *this; }

/*
** Add_Ref, call this function if you are going to keep a pointer to this object.
*/
Expand Down
Loading