> On Dec 13, 2017, at 11:44 AM, Leonard Mosescu via lldb-dev
> <lldb-dev@lists.llvm.org> wrote:
>
> LLDB's C++ API deals with SBxxx objects, most of which are PIMPL-style
> wrappers around an opaque pointer to the internal implementation. These SBxxx
> objects act as handles and are passed/returned by value, which is generally
> convenient, except for the situations where one would need to keep track of
> object identities, ex. using them as keys in associative containers.
>
> As far as I can tell, there's a bit of inconsistency in the current state:
>
> 1. Some types, ex. SBThread, SBTarget, SBSection, ... offer ==, != that map
> directly to the corresponding operator on the opaque pointer (good!), but:
> .. there are no ordering operators, nor obvious ways to hash the objects
> 2. SBModule offer the == , != operators, but:
> ... the implementations for == and != are not exactly forwarded to the
> corresponding operator on the opaque pointer (1)
> 3. Things like SBFrame offer IsEqual() in addition to ==, !=, creating a bit
> of confusion
> 4. Other types (ex. SBProcess, SBSymbol, SBBlock) don't offer any kind of
> comparison operations.
>
> IMO it would be nice to have a consistent "handle type" semantics regarding
> identity, ordering and hashing. I can see the following options:
>
> 1. Expose the opaque ptr as an opaque handle()
> - this is an easy, quick and convenient solution for many SBxxx types
> but it may not work for all
That would be nice, but that won't always work with how LLDB is currently coded
for SBFrame and possibly SBThread. These objects will be problems as they can
come and go and the underlying object isn't always the same even through they
lock onto the same logical object. SBThread and SBFrame have
"lldb::ExecutionContextRefSP m_opaque_sp" members. The execution context
reference is a class that contains weak pointers to the lldb_private::Thread
and lldb_private::StackFrame objects, but it also contains the thread ID and
frame ID so it can reconstitute the value lldb_private::Thread and
lldb_private::StackFrame even if the weak pointer isn't valid. So the opaque
handle will work for many objects but not all.
> 2. Design and implement a consistent, first class identity/ordering/hashing
> for all the SBxxx types
> - perhaps the most elegant and flexible approach, but also the most work
I would be fine with adding new members to classes we know we want to hash and
order, like by adding:
uint32_t SB*::GetHash();
bool SB*::operator==(const SB*& ohs);
bool SB*::operator<(const SB*& ohs);
Would those be enough?
>
> Any thoughts on this? Did I miss anything fundamental here?
>
> Thanks,
> Lemo.
>
> (1) example of operator== from SBModule:
>
> bool SBModule::operator==(const SBModule &rhs) const {
> if (m_opaque_sp)
> return m_opaque_sp.get() == rhs.m_opaque_sp.get();
> return false;
> }
So I would leave this up to the SB classes so that we can change the
implementation if needed so I would prefer to add methods to each SB object for
hashing and comparison.
Greg Clayton
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
