On Thu, Sep 29, 2016 at 10:43 AM Enrico Granata <egran...@apple.com> wrote:
> On Sep 28, 2016, at 5:58 PM, Zachary Turner <ztur...@google.com> wrote:
>
>
>
> On Wed, Sep 28, 2016 at 4:02 PM Enrico Granata via lldb-commits <
> lldb-commits@lists.llvm.org> wrote:
>
>
> -
> +
> + static ConstString g___i_("__i_");
> +
> // this must be a ValueObject* because it is a child of the ValueObject
> we are
> // producing children for
> // it if were a ValueObjectSP, we would end up with a loop (iterator ->
> @@ -281,6 +287,57 @@ bool lldb_private::formatters::LibCxxMap
> SyntheticChildrenTraversal::None),
> nullptr)
> .get();
> +
> + if (!m_pair_ptr) {
> + m_pair_ptr = valobj_sp->GetValueForExpressionPath(".__i_.__ptr_",
> nullptr, nullptr, nullptr,
> +
> ValueObject::GetValueForExpressionPathOptions()
> +
> .DontCheckDotVsArrowSyntax()
> +
> .SetSyntheticChildrenTraversal(
> +
> ValueObject::GetValueForExpressionPathOptions::
> +
> SyntheticChildrenTraversal::None),
> + nullptr)
> + .get();
> + if (m_pair_ptr) {
> + auto __i_(valobj_sp->GetChildMemberWithName(g___i_, true));
>
> Is there any reason we need to use such weird variable names? This looks
> like undefined behavior to me. Variables with more than one adjacent
> underscore are reserved.
>
>
> I am naming the variable the same as the corresponding variable in the
> type I am formatting. Future me is usually thankful when I do that.. it
> helps keep track of what ValueObject matches what child element; in this
> case, our iterators have an __i_ child
>
Ahh, makes sense. Unfortunately at least in this case it leads to illegal
variable names. Is there anything else it could be named that would be
similar enough to help remembering but a valid c++ identifier?
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
