Re: [RFC] Using std::unique_ptr and std::make_unique in our code

[Pedro Alves <pedro@palves.net>]

On 2022-07-12 11:21 a.m., Florian Weimer wrote:
> * Pedro Alves:
> 
>> For example, for the type above, we'd have:
>>
>>   typedef std::unique_ptr<pending_diagnostic> pending_diagnostic_up;
>>
>> and then:
>>
>>  -				    pending_diagnostic *d,
>>  +				    pending_diagnostic_up d,
>>
>> I would suggest GCC have a similar guideline, before people start
>> using foo_ptr, bar_unp, quux_p, whatnot diverging styles.
> 
> This doesn't seem to provide much benefit over writing
> 
>   uP<pending_diagnostic> d;
> 
> and with that construct, you don't need to worry about the actual
> relationship between pending_diagnostic and pending_diagnostic_up.

Given the guideline, nobody ever worries about that.  When you see "_up",
you just know it's a unique pointer.

And as you point out, there's the custom deleters case to consider too.

> 
> I think the GDB situation is different because many of the types do not
> have proper destructors, so std::unique_ptr needs a custom deleter.

Yes, there are a few cases like but it's not "many" as you suggest,
and most are types for which we have no control, like 3rd party library
types, like debuginfod, curses, python.  Most of the rest of the custom deleter cases
are instead because of intrusive refcounting.  I.e., the deleter decrements the
object's refcount, instead of deleting the object straight away.

These are valid cases, not "GDB is doing it wrong, so GCC won't have to
bother".  I would suspect that GCC will end up with a good number of
custom deleters as well.