[cfe-commits] r154248 - in /cfe/trunk: include/clang/Basic/DiagnosticSemaKinds.td include/clang/Sema/Sema.h lib/Sema/SemaAccess.cpp lib/Sema/SemaDeclCXX.cpp lib/Sema/SemaExprCXX.cpp lib/Sema/SemaInit.cpp test/CXX/class.access/class.protected/p1.c
Francois Pichet
pichet2000 at gmail.com
Tue Apr 10 07:36:08 PDT 2012
On Mon, Apr 9, 2012 at 1:34 PM, John McCall <rjmccall at apple.com> wrote:
> On Apr 8, 2012, at 2:29 AM, Francois Pichet wrote:
>> On Fri, Apr 6, 2012 at 11:04 PM, John McCall <rjmccall at apple.com> 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;
>> }
>
>
> It should be trivial to disable the additional restrictions in MicrosoftMode.
> Does MSVC implement the protected member access restriction at all,
> or does it just miss it in the case of pointer-to-members?
>
> Try this:
>
> void B::test() {
> A *a = 0;
> a->f();
> }
MSVC will give an error for this case.
So MSVC just seem to miss the pointer-to-members case and this cause a
regression with MFC code.
More information about the cfe-commits
mailing list