On Sep 7, 2005, at 12:19 PM, Michael Tegtmeyer wrote:
This doesn't need to be that sophisticated.
So, the answer can be wrong and code generation won't be wrong? I
don't know what you mean by *could have been* accessed. I don't even
know what you mean by member.
So in this case, I do not even need to know what is going on at the
call site (which obviously simplifies things). Since you pointed me
to the front end, do you know if there is a simple way of walking
the inheritance type hierarchy to determine this?
I don't know what `this' refers to, so hard to answer.
Right now I'm just walking it through the ..._CONTEXTs
TYPE_CONTEXT, DECL_CONTEXT, DECL_CLASS_CONTEXT, DECL_FIELD_CONTEXT or
DECL_FRIEND_CONTEXT or DECL_FCONTEXT? :-)
but it seems clumsy
No, not too clumsy, just wrong if you need accurate answers and the
definition of member includes MI base class members.
You can check out dbxout.c:
tree binfo = TYPE_BINFO (type);
if (BINFO_N_BASE_BINFOS (binfo))
for (i = 0; BINFO_BASE_ITERATE (binfo, i, child); i++)
for hints on how to walk the class hierarchy in the backend.
#define TREE_PRIVATE(NODE) ((NODE)->common.private_flag)
#define TREE_PROTECTED(NODE) ((NODE)->common.protected_flag)
are how fields are marked as public, private and protected, though,
if you need right answers, you will have to know C++ and its various
rules, such as you can get at private members, as long as they are
also found non-privately.
