Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does Base_subobject also needs access specifier? #267

Open
GorNishanov opened this issue May 19, 2022 · 0 comments
Open

Does Base_subobject also needs access specifier? #267

GorNishanov opened this issue May 19, 2022 · 0 comments

Comments

@GorNishanov
Copy link
Contributor

GorNishanov commented May 19, 2022

Consider:

struct A {};
struct B {};

struct C : protected B, private A {};

Prior to introduction of subobjects, base_type was a declaration that had DeclSpecifiers that could encode both AccessProtection and virtual-ness of the base:

   enum class DeclSpecifiers : std::uint32_t {
       ...
      Virtual    = 1 << 6,   // also used as storage class specifier
                             // for virtual base subobjects
       ...
      Public     = 1 << 11,
      Protected  = 1 << 12,
      Private    = 1 << 13,
      AccessProtection = Public | Protected | Private,
       ...
   };

Looking at current definition of Base_subobject:

   // Specifier of semantics for base-class subobjects.
   enum class Subobject_specifier : std::uint8_t {
      Exclusive,                    // Each subobject is unshared, default in ISO C++
      Shared,                       // "virtual" subobject shared along inheritance chain
   };

                                // -- Base_subobject --
   // Each base-specifier in a base-clause morally declares an unnamed subobject.
   struct Base_subobject {
      virtual const Type& type() const = 0;
      virtual Subobject_specifier specifier() const = 0;
   };

it seems that we may have lost an ability to encode access protection for bases

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant