clayborg wrote:
> This class behaves quite differently from other SB API classes. Normally, the
> opaque pointer can be cleared to release the potentially more resource heavy
> private counterpart. `AddressRange` is a pretty simple class, so I understand
> that it makes things easier if we guarantee the pointer is always valid, but
> it is somewhat of a surprise.
>
> Personally, I think consistency beats the small advantage of not having to
> check the pointer. If we want to stick to this approach, I'd like to see an
> assert that makes it clear that in this class, we have a precondition that
> the pointer is always valid:
>
> ```
> assert(m_opaque_up && "opaque pointer must always be valid");
> ```
For simple classes, there is no need to clear the unique pointer, so I like
this approach for small classes.
We can use the assert in a new protected `ref()` method:
```
lldb_private::AddressRange & SBAddressRange::ref() {
assert(m_opaque_up && "opaque pointer must always be valid");
return *m_opaque_up;
}
```
And then have everything that accesses `m_opaque_up` use the `ref()` function.
It is similar to other classes and makes the code nicer when we don't see
direct uses of `m_opaque_up`
https://github.com/llvm/llvm-project/pull/95997
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
