Yea :( In practice you're right that it might not ever be an issue, but I
know one time I spent quite a long time trying to figure out why I couldn't
create a variable named "unix", so any time I see questionable names it
brings back terrible memories.
On Thu, Sep 29, 2016 at 10:58 AM Enrico Granata <egran...@apple.com> wrote:
>
> On Sep 29, 2016, at 10:50 AM, Zachary Turner <ztur...@google.com> wrote:
>
>
>
> 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?
>
>
> Sure, we just add a "vo" prefix, like vo__i_
>
> I thought the rule about __ being magic only applied to global
> identifiers, and I have never seen any compiler complain about those
> identifiers in practice. But reserved is reserved, so thanks for pointing
> that out.
>
> Thanks,
> *- Enrico*
> 📩 egranata@.com ☎️ 27683
>
>
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
