This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 4/7] Move struct varobj to varobj.h.
- From: Doug Evans <dje at google dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Yao Qi <yao at codesourcery dot com>, gdb-patches at sourceware dot org
- Date: Wed, 2 Oct 2013 12:32:25 -0700
- Subject: Re: [PATCH 4/7] Move struct varobj to varobj.h.
- Authentication-results: sourceware.org; auth=none
- References: <1379512482-31773-1-git-send-email-yao at codesourcery dot com> <1379512482-31773-5-git-send-email-yao at codesourcery dot com> <20131002094636 dot GC2971 at adacore dot com>
Joel Brobecker writes:
> > This patch moves most of the fields of struct varobj to varobj.h, and
> > continue to name it 'struct varobj.h' there. New struct
> > varobj_dynamic 'extends' struct varobj in varobj.c.
> >
> > Move part of struct varobj to varobj.h
> >
> > gdb:
> >
> > 2013-09-18 Yao Qi <yao@codesourcery.com>
> >
> > * varobj.c (struct varobj): Move most of the fields to
> > varobj.h.
> > (struct varobj_dynamic): New struct.
> > (varobj_get_display_hint) [HAVE_PYTHON]: Cast 'var' to type
> > 'struct varobj_dynamic'.
> > (varobj_has_more): Likewise.
> > (dynamic_varobj_has_child_method): Change type of parameter
> > 'var' to 'struct varobj_dynamic *'.
> > (update_dynamic_varobj_children): Likewise.
> > (install_visualizer): Likewise.
> > (install_default_visualizer, construct_visualizer): Likewise.
> > (varobj_get_num_children): Likewise.
> > (dynamic_varobj_has_child_method): Adjust.
> > (varobj_list_children, varobj_get_attributes): Likewise.
> > (varobj_set_value, install_new_value): Likewise.
> > (varobj_update, new_variable): Likewise.
> > (my_value_of_variable, value_get_print_value): Likewise.
> > * varobj.h (struct varobj): Moved from varobj.c.
>
> Overall, I like the direction that the whole series is taking.
Me too.
> But this is a patch that makes me a little uncomfortable, because
> I am not sure really want to introduce this kind of polymorphism
> where we cast struct varobj into struct varobj_dynamic.
Me too. :-)
> I would
> need to think about it some more - it seems to me that at the root
> of things, we are always manipulating a varobj_dynamic so it is
> always safe to cast it. But this then begs the question why not
> declare them as struct varobj_dynamic in the first place. The answer
> is probably that we don't want to expose too much of struct varobj,
> and in particular the part dealing with dynamicity and pretty-printers.
We don't have "private" but, heh, Python doesn't either except by convention.
So ... we *could* have a similar convention.
Just a thought for discussion's sake ... :-)
[If C++ is around the corner one might punt, though it couldn't hurt
to document (in some way) what's private and what's not today.]
> Perhaps, and this is thinking out loud, another approach would be
> to make this data part of the public struct varobj, but inside
> an opaque structure?
"works for me"
There's only one constructor (I think), it could handle the details.
> I'd really like feedback from other maintainers who have experience
> in this area...
IWBN to have something that didn't use casting alright.