[SERVER-53039] SpecificStats::clone() should return a unique_ptr rather than a raw pointer Created: 23/Nov/20  Updated: 29/Oct/23  Resolved: 09/Feb/21

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: 4.9.0

Type: Improvement Priority: Major - P3
Reporter: Anton Korshunov Assignee: Yoon Soo Kim
Resolution: Fixed Votes: 0
Labels: neweng, qexec-team
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Query Execution 2021-02-22
Participants:

 Description   

There is no apparent reason to return a raw pointer when cloning a SpecificStats instance and we should take advantage of unique_ptr whenever possible.



 Comments   
Comment by Githook User [ 09/Feb/21 ]

Author:

{'name': 'Yoonsoo Kim', 'email': 'yoonsoo.kim@mongodb.com', 'username': 'yun-soo'}

Message: SERVER-53039 Make SpecificStats::clone() return unique_ptr
Branch: master
https://github.com/mongodb/mongo/commit/f9cc115ef03eef4e8a018585c73d0c86751217f7

Comment by Ian Boros [ 02/Feb/21 ]

I don't expect the cascade effect to be that bad, given the SBE codebase is still pretty new. In the rest of the codebase we make a pretty good effort at avoiding raw new/delete invocations, so IMO this is definitely a worthwhile improvement.

Functions which take a SpecificStats* raw pointer can continue to do so, but yes, I do expect a lot of call sites would have to change.

As always, if you have any questions feel free to message me. 

Comment by Yoon Soo Kim [ 02/Feb/21 ]

SpecificStats is an interface and its clone() method returns a raw pointer. If we change its return type to unique_ptr, then every caller of SpecificStats::clone() method should be modified too if the caller code does not use auto. Any function which takes a raw pointer of SpecificStats is also likely to be modified. The interface function signature modification may cause cascade effects unless our codebase is almost ready to use unique_ptr. Let me research this further.

Generated at Thu Feb 08 05:29:45 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.