[cfe-dev] private class members access fails with meta-programming in clang?

Richard Smith richard at metafoo.co.uk
Thu Apr 25 08:48:32 PDT 2013


On Thu, Apr 25, 2013 at 1:01 AM, Handa, Ramneek <Ramneek.Handa at sc.com>wrote:

> I am confused on how to find this in the std document.
> What I find in there is (from n3485):
> 1. Page-231, clause 4 - Access control is applied uniformly to all
> names, whether the names are referred to from declarations or
> expressions.
> 2. Page-231, clause 5 - It should be noted that it is access to members
> and base classes that is controlled, not their visibility. Names
> of members are still visible, and implicit conversions to base classes
> are still considered, when those members
> and base classes are inaccessible. The interpretation of a given
> construct is established without regard to
> access control. If the interpretation established makes use of
> inaccessible member names or base classes, the
> construct is ill-formed.
>
> I am not sure what they mean by visibility?
>
> Could you send me what sections and clauses are you referring to?
>

We're not a C++ support forum; your question might be better directed to
stackoverflow. If you want to understand how the C++11 rules differ from
C++03, you should compare the C++11 and C++03 standards. Search for things
like "would be ill-formed" and "type deduction fails".

If you think that Clang is actually wrong here (if this code is still
rejected with -std=c++11, for instance), please provide preprocessed (and
preferably reduced) source code.


> Thanks for response again.
>
> Regards.
>
>
> -----Original Message-----
> From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu]
> On Behalf Of John McCall
> Sent: Thursday, April 25, 2013 2:27 PM
> To: Ramneek Handa
> Cc: clang-dev Developers
> Subject: Re: [cfe-dev] private class members access fails with
> meta-programming in clang?
>
> On Apr 24, 2013, at 9:20 AM, Ramneek Handa <ramneekhanda at gmail.com>
> wrote:
> > I thought this should pass with clang.
> >
> > x-- start --x
> >
> > #include <boost/mpl/has_xxx.hpp>
> >
> > BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF(hasSomething, Data, false);
> >
> > class A {
> > private:
> > struct Data {
> > };
> > };
> >
> >
> > void function(bool val = hasSomething<A>::value) {}
> >
> >
> > x-- end --x
> >
> > however it produces following output:
> > test_private_data.cpp:3:49: error: 'Data' is a private member of 'A'
> > BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF(hasSomething, Data, false);
> > ^
> > /usr/include/boost/mpl/has_xxx.hpp:195:68: note: expanded from macro
> 'BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF'
> > , boost::mpl::aux::type_wrapper<BOOST_MSVC_TYPENAME U::name>* = 0 \
> > ^
> > test_private_data.cpp:3:1: note: while substituting deduced template
> arguments into function template 'test' [with U = A]
> > BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF(hasSomething, Data, false);
> > ^
> > /usr/include/boost/mpl/has_xxx.hpp:193:41: note: expanded from macro
> 'BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF'
> > static boost::mpl::aux::yes_tag test( \
> > ^
> > test_private_data.cpp:12:26: note: in instantiation of template class
> 'hasSomething<A, mpl_::bool_<false> >' requested here
> > void function(bool val = hasSomething<A>::value) {}
> > ^
> > 1 error generated.
> > /usr/bin/ld: /tmp/test_private_data-Hatffv.o: No such file: No such
> file or directory
> > clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> >
> >
> >
> >
> > BUT it passes with GCC.
> >
> > Which one is right?
>
> I assume that Boost is using SFINAE here in its check.  Access control
> violations were not subject to SFINAE prior to C++11, and Clang is
> correct
> to diagnose it.  You can compile with -std=c++11 to make this work;  the
> trait will return 'false'.
>
> John.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
> This email and any attachments are confidential and may also be
> privileged. If you are not the intended recipient, please delete all copies
> and notify the sender immediately. You may wish to refer to the
> incorporation details of Standard Chartered PLC, Standard Chartered Bank
> and their subsidiaries at
> http://www.standardchartered.com/en/incorporation-details.html.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130425/ba4fe96c/attachment.html>


More information about the cfe-dev mailing list