SBDebugger CreateTarget question

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?

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.

Matthew,

You'll know that target creation failed because the SBTarget will be invalid, you just won't know why. There are a bunch of short-cut methods like this that are convenient to call when you are just poking at the API by hand in the "script" command in lldb, but shouldn't be used if you are writing real programs. In the long run, we should deprecate the ones of these that are obviously dangerous, and then remove them in the fabled 2.0 version of the lldb API's, though in practice having some "quick and dirty" interfaces is not always bad.

Jim

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. We should mark the other three as deprecated. The test suite uses these all over the place which we can/should fix to use the first.

Greg

Ok, thanks Jim

Matt

>
> 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.. :slight_smile:

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.