mib added a comment.

In D117139#3240436 <https://reviews.llvm.org/D117139#3240436>, @labath wrote:

> I'd like to remind everyone of a not-very-widely-known, but incredibly nifty 
> feature of std::shared_ptr, called "aliasing". It allows one to create a 
> shared_ptr which points to one object, but deletes a completely different 
> object when it goes out of scope. It works like so:
>
>   std::shared_ptr<A> a = std::make_shared<A>(...); // or whatever
>   std::shared_ptr<B> b(a, getB(a)); // will point to a B, but call `delete A` 
> when it goes out of scope
>
> The model use case is when the first object is a subobject (field) of the 
> second one (so we'd have `struct A { B b; ... };` and `getB(a)` would be 
> `&a->b`), but that is not a a requirement. B can be a completely arbitrary 
> object -- the only requirement is that B remains live for as long as A is 
> around.

Very neat indeed, but I don't think it will be of any use here unfortunately: 
IIUC in your example, `b` is the first to go out-of-scope which calls `a` 
destructor. In my case, `a` when out of scope but it still referenced by `b`.

> Now, I don't understand this code well enough to say whether that 
> could/should be used here, but the (few) parts which I did understand led me 
> to think that there are some subobjects (in the broadest sense of the word) 
> being passed around, and so I have a feeling we should at least consider this 
> option -- it seems like it would be better to pass around objects with 
> explicit ownership semantics instead of raw pointers.

I agree with you on theory but here, the `ScriptedThreadInterface` tries to be 
language-agnostic that's why I pass `StructuredData::GenericSP` around.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D117139/new/

https://reviews.llvm.org/D117139

_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to