Description
While backporting JDK-8234779 I noticed a handful of additional cases where the NONCOPYABLE macro should probably be applied. For example, in src/hotspot/share/utilities/formatBuffer.hpp.
I think the best way to identify any remaining cases like this is to manually examine every place where a copy constructor is declared. This approach is practical as there only seems to be about 30 copy constructors in mainline at the moment. I believe something like the following search should catch all of them:
===
find . -name "*.hpp" |xargs grep -E '\b(\w+)\s*[\(]\s*(const)*\s*(volatile)*\s*\1\s*[&]\s*\w*\s*[\)]'
===
We should look at each result one-by-one and determine if the author was trying to prevent copying. We can replace these cases with the NONCOPYABLE macro where appropriate.
I think the best way to identify any remaining cases like this is to manually examine every place where a copy constructor is declared. This approach is practical as there only seems to be about 30 copy constructors in mainline at the moment. I believe something like the following search should catch all of them:
===
find . -name "*.hpp" |xargs grep -E '\b(\w+)\s*[\(]\s*(const)*\s*(volatile)*\s*\1\s*[&]\s*\w*\s*[\)]'
===
We should look at each result one-by-one and determine if the author was trying to prevent copying. We can replace these cases with the NONCOPYABLE macro where appropriate.
Attachments
Issue Links
- duplicates
-
JDK-8234779 Provide idiom for declaring classes noncopyable
-
- Resolved
-
- relates to
-
-
- Resolved
-
