[lldb-dev] SBDebugger CreateTarget question

[Matthew Gardiner]

On Thu, 2014-10-09 at 10:42 -0700, Greg Clayton wrote:
> > On Oct 9, 2014, at 3:53 AM, Matthew Gardiner <mg11 at csr.com> wrote:
> > 
> > Hi,
> > 
> > I'm starting to play with the C++ API some more. I'm looking at target
> > creation on the SBDebugger class:
> > 
> >    lldb::SBTarget
> >    CreateTarget (const char *filename,
> >                  const char *target_triple,
> >                  const char *platform_name,
> >                  bool add_dependent_modules,
> >                  lldb::SBError& error);
> > 
> >    lldb::SBTarget
> >    CreateTargetWithFileAndTargetTriple (const char *filename,
> >                                         const char *target_triple);
> > 
> >    lldb::SBTarget
> >    CreateTargetWithFileAndArch (const char *filename,
> >                                 const char *archname);
> > 
> >    lldb::SBTarget
> >    CreateTarget (const char *filename);
> > 
> > Out of the 4 methods of target creation, why has only one function got a
> > mechanism to pass back an error?
> > 
> > How can I use the remaining 3 functions without such a scheme?
> 
> You should always use the first one that has the error.
> The other 3 that take less args were there before this
> first one and are there for legacy reasons. Just pass
> NULL (C++) or None (Python) for anything that you don't want to specify.

Thanks. Yes, I guessed at this and it worked. I just thought I'd send my
post to flag up that it seemed a bit grotty.

I've a lot of experience in the design of C (but not C++) APIs. With
those I'd always advocate returning an integer as an error code, and any
"object created by the function call" as a handle in one of the output
parameters. If I had any influence at all on the design of version2 of
this (C++) API then I'd opt to *always* return an SBError for every
call, and return new objects as a "reference to smart pointer". That's
my take.

Anyway, thanks for the above confirmation

> We should mark the other three as deprecated.

Agreed.

>  The test suite uses these all over the place which we can/should fix to use the first.

That's the problem with APIs.. :-)

thanks
Matt




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.