Well, yes, a clean API design would (eventually) move the
Initialise/Terminate functions out of the scope the SBDebugger entity.
Matt
On Thu, 2014-10-09 at 09:07 -0700, jing...@apple.com wrote:
> Yes, I don't think we can remove SBDebugger::Initialize/Terminate, but we
> could document them:
>
> (lldb) script
> Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.
> >>> help(lldb.SBDebugger.Initialize)
> Help on function Initialize in module lldb:
>
> Initialize()
> Initialize()
>
> We could even add lldb::Initialize & Terminate and say in the
> SBDebugger::Initialize & Terminate that we'll get rid of them at some point,
> so use the lldb:: ones instead.
>
> Jim
>
>
> > On Oct 8, 2014, at 10:16 PM, Matthew Gardiner <m...@csr.com> wrote:
> >
> > Thanks Greg,
> >
> > Yes, my confusion stemmed from the scoping of the functions.
> >
> > It would have been better, as you'd stated, if we'd have got:
> >
> > namespace lldb {
> > void Initialize();
> > void Terminate();
> > }
> >
> > But I appreciate that the C++ API is hard to change. Sorry about
> > previous confusion.
> >
> > There's a couple of additions I would like to make to the API soon,
> > which will benefit the kalimba non-8-bit byte stuff. I'll build test
> > cases first and add a review before doing anything drastic first.
> >
> > thanks
> > Matt
> >
> >
> > On Wed, 2014-10-08 at 11:26 -0700, Greg Clayton wrote:
> >>> On Oct 7, 2014, at 10:15 PM, Matthew Gardiner <m...@csr.com> wrote:
> >>>
> >>> On Tue, 2014-10-07 at 17:10 -0700, Greg Clayton wrote:
> >>>> It is quite common for shared libraries to have initialize and terminate
> >>>> calls. We have this in LLDB.
> >>>
> >>> Agreed. Lots of libraries have to initialise resource, then release the
> >>> resource upon terminate.
> >>>
> >>> But why have an Initialise method when you _already_ have a Create
> >>> method? Likewise a Terminate method when you _already_ have a Destroy
> >>> method.
> >>>
> >>> Surely when a "thing" is created that is also when it is initialised?
> >>
> >> You are assuming there is no global context within the debugger like all
> >> registered plug-ins, lists, settings, global module list... These all work
> >> without requiring a debugger object. We could switch things so that all
> >> state is contained in the lldb_private::Debugger object, but then all
> >> places making static function calls would now need to have a debugger
> >> object. So think of SBDebugger::Initialize() more of a LLDB::Initialize()
> >> and SBDebugger::Terminate() as LLDB::Terminate(). We placed it into the
> >> SBDebugger class just for convenience since this is the most senior object
> >> in the hierarchy, but I can see how this is confusing.
> >>
> >>
> >>>
> >>>>
> >>>> I would rather not have to look through all API calls that might require
> >>>> LLDB to be initialized and have to possibly manually call
> >>>> SBDebugger::Initialize() in there. The initialization does quite a bit
> >>>> and the assertion quickly should tell you that you must call
> >>>> SBDebugger::Initialize() first. If it isn't clear from the assertion, we
> >>>> can change the assertion to be more descriptive. But again, many other
> >>>> classes in the lldb::SB* API have functions that might be able to be
> >>>> used without having to start with a debugger, so I would rather not have
> >>>> to go through all of the API and add the "init the debugger if not
> >>>> already initialized".
> >>>>
> >>>> This also allows you to use LLDB as a shared library and do:
> >>>>
> >>>> SBDebugger::Initialize()
> >>>> // Do something that takes up a bunch of memory
> >>>> SBDebugger::Terminate()
> >>>>
> >>>
> >>> Agreed. But surely in between the invocations of Initialise and
> >>> Terminate, you have in some sense "created" an instance of an
> >>> SBDebugger?
> >>
> >> No that isn't required. There are other API calls you might be able to use
> >> (not many). Repeating what I stated above:
> >> SBDebugger::Initialize()/Terminate() are more really like
> >> LLDB::Initialize() and LLDB::Terminate(), so these calls are really things
> >> that populate all shared library globals.
> >>>
> >>>
> >>>> So I vote to leave things as is.
> >>>>
> >>>
> >>> To avoid rocking the boat, I reluctantly concede.
> >>
> >> Since we already have this in the SBDebugger public API I would rather not
> >> change it, but it would be probably clearer if we had:
> >>
> >> namespace lldb {
> >> void Initialize(); // Must be called prior to calling any other
> >> lldb::SB API calls
> >> void Terminate(); // No lldb::SB API calls should be called after
> >> calling this and before calling lldb::Initialize() again
> >> }
> >>
> >> Does that help explain what SBDebugger::Initialize() and
> >> SBDebugger::Terminate() actually are despite the wrong class scoping?
> >>
> >> Greg
> >>
> >>
> >>
> >>
> >> To report this email as spam click
> >> https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ== .
> >
> >
> >
> >
> > Member of the CSR plc group of companies. CSR plc registered in England and
> > Wales, registered number 4187346, registered office Churchill House,
> > Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
> > More information can be found at www.csr.com. Keep up to date with CSR on
> > our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people,
> > YouTube, www.youtube.com/user/CSRplc, Facebook,
> > www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at
> > www.twitter.com/CSR_plc.
> > New for 2014, you can now access the wide range of products powered by aptX
> > at www.aptx.com.
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev@cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
