[Lldb-commits] [PATCH] Expose ThreadCollection in SB API
egranata at apple.com
Fri Sep 5 14:35:03 PDT 2014
- why do you need stdio.h in your header file?
- is there any reason why this constructor is public?
+ SBThreadCollection (const lldb::ThreadCollectionSP &thread_list);
We are usually trying to keep the constructors that take SPs protected so they are not exposed to API clients; unless you have a compelling reason, I’d do the same here
For instance, SBData has the following:
// Mimic shared pointer...
const lldb::DataExtractorSP &
SBData (const lldb::DataExtractorSP &data_sp);
SetOpaque (const lldb::DataExtractorSP &data_sp);
You could so something similar in your SBThreadCollection; provide protected accessors, constructor and setter, and only keep the default & copy constructors public
On a more philosophical note - is SBThreadCollection meant as a “read-only” snapshot of a set of threads as they existed at one time?
If so, then it’s all fine and dandy
But it seems that this class lacks any write access; I can’t create a new thread collection and start adding threads to it
Is this intended in your design, or did you just not feel the need to allow that?
> On Sep 5, 2014, at 2:20 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote:
> Another piece of the puzzle, let's expose the newly abstracted ThreadCollection into SB API, based on http://reviews.llvm.org/D5200 and another patch that will actually provide an SBThreadCollection of ASan history threads is coming next.
> lldb-commits mailing list
> lldb-commits at cs.uiuc.edu
📩 egranata@.com ☎️ 27683
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-commits