[Lldb-commits] [PATCH] D13778: [SBValue] Add a method HasChildAtIndex.

Siva Chandra via lldb-commits lldb-commits at lists.llvm.org
Thu Oct 15 12:19:59 PDT 2015


On Thu, Oct 15, 2015 at 11:59 AM, Enrico Granata
<granata.enrico at gmail.com> wrote:
> granata.enrico added a comment.
>
> So, if I understand this correctly, this HasChildAtIndex() API returns a three-state int:
>
> 1 == yes I do
> 0 == no I do not
> -1 == maybe, can't tell
>
> When would you ever run into the -1 case? It seems you're mostly using it as an
> invalid marker. Would 0 not be a better choice for those invalid cases? Then you
> could just use a boolean which seems a better answer for an inherently yes/no
> question (invalid objects do not have a child at index for any index, do they?)

So, I don't expect "may be, can't tell" to be an answer given by a
synthetic child provider. It should be 'True' or 'False'. The value of
'-1' is returned by SBValue API when there does not exist a
"has_child_at_index" method (as it is optinal), or if there is some
error executing that method.

> Also, if you're only using this from inside a synthetic child provider, why does it need to be
> in SBValue? Or is your argument that you want to write scripts against LLDB that use this
> feature?

We use the SBValue API from out IDE to fetch the number of children of
a value. But the fact is, we use GetNumChildren because we do not have
an alternative. We really do not want to know the full number of
children for any value. All we are interested in is something like,
"do you have 50?", "well, do you have 100 then?" etc. With this
change, we are pushing for an alternative which bounds the time spent
to get the answer to such questions. This change alone will not
completely solve our problem. We will have to adjust our
data-formatters to be stateful when implementing the new API.

> Truth be told, I am not particularly excited about this feature, and the fact that this seems
> to be introduced in a vacuum does nothing to assuage my original concern that is is a
> potentially avoidable complication to the model.

I am open to suggestions which achieve the same in a different manner.


More information about the lldb-commits mailing list