On Fri, Apr 6, 2012 at 11:04 PM, John McCall <[email protected]> wrote:
> Author: rjmccall
> Date: Fri Apr 6 22:04:20 2012
> New Revision: 154248
>
> URL: http://llvm.org/viewvc/llvm-project?rev=154248&view=rev
> Log:
> Fix several problems with protected access control:
> - The [class.protected] restriction is non-trivial for any instance
> member, even if the access lacks an object (for example, if it's
> a pointer-to-member constant). In this case, it is equivalent to
> requiring the naming class to equal the context class.
> - The [class.protected] restriction applies to accesses to constructors
> and destructors. A protected constructor or destructor can only be
> used to create or destroy a base subobject, as a direct result.
> - Several places were dropping or misapplying object information.
>
> The standard could really be much clearer about what the object type is
> supposed to be in some of these accesses. Usually it's easy enough to
> find a reasonable answer, but still, the standard makes a very confident
> statement about accesses to instance members only being possible in
> either pointer-to-member literals or member access expressions, which
> just completely ignores concepts like constructor and destructor
> calls, using declarations, unevaluated field references, etc.
>
Hi John,
I am not asking you to make the modification but do you have any
suggestion about how to handle case like that in MicrosoftMode?
class A {
protected:
void f();
};
class B : public A{
public:
void test();
};
void B::test() {
&A::f;
}
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
