Using declaration in private section

[Marcin Kalicinski]

Hi,

Because public inheritance should be used to model is-a relationship, is it
evil from a design point of view to disallow some operations from base
class?

class Derived: public Base
{
/* ... */
private:
using Base::SomeOperation; // Disallow
}

Best regards,
Marcin

 

[Victor Bazarov]

Because public inheritance should be used to model is-a relationship, is it
evil from a design point of view to disallow some operations from base
class?

class Derived: public Base
{
/* ... */
private:
using Base::SomeOperation; // Disallow
}

;


To answer your question, no, it doesn't work that way. The access
specifiers only work in one direction -- from more strict to less
strict. They are designed to _allow_ things that are not allowed
by default, not to _prohibit_ things that are otherwise accessible.

In order to achieve what you need you need to derive privately or
protectedly and then declare the ones that you want to allow as
used or define wrapper interfaces for them.

Victor

 

[Marcin Kalicinski]

To answer your question, no, it doesn't work that way. The access
specifiers only work in one direction -- from more strict to less
strict. They are designed to _allow_ things that are not allowed
by default, not to _prohibit_ things that are otherwise accessible.

You mean that the above example will not physically prohibit using
SomeOperation? Or just that is should not be used in that way?

To be sure I checked it with MS VC 7.1, and I could not use SomeOperation
when it was redeclared in private section of derived class:

a.cpp(14) : error C2248: 'Derived::SomeOperation' : cannot access private
member declared in class 'Derived'

Marcin

 

[Victor Bazarov]

You mean that the above example will not physically prohibit using
SomeOperation? Or just that is should not be used in that way?

To be sure I checked it with MS VC 7.1, and I could not use SomeOperation
when it was redeclared in private section of derived class:

a.cpp(14) : error C2248: 'Derived::SomeOperation' : cannot access private
member declared in class 'Derived'

OK, after re-reading the Standard, I must say I was mistaken. The
using declaration can be used to adjust the access. You're right.

BTW, Comeau C++ has a bug, AFAICT. It compiles this:

struct A {
void foo();
};

struct B : A {
private:
using A::foo;
};

int main() {
A a;
a.foo();
B b;
b.foo(); // should be an error here -- inaccessible 'foo'
b.A::foo(); // OK, a way to circumvent access specifiers
}

without an error.

Now, after re-reading your original post, yes, it would go against
principles of OOD. As such you may label it "evil" or "bad practice"
or whatever.

Victor

 

[Greg Comeau]

OK, after re-reading the Standard, I must say I was mistaken. The
using declaration can be used to adjust the access. You're right.

BTW, Comeau C++ has a bug, AFAICT. It compiles this:

struct A {
void foo();
};

struct B : A {
private:
using A::foo;
};

int main() {
A a;
a.foo();
B b;
b.foo(); // should be an error here -- inaccessible 'foo'
b.A::foo(); // OK, a way to circumvent access specifiers
}

without an error.

Now, after re-reading your original post, yes, it would go against
principles of OOD. As such you may label it "evil" or "bad practice"
or whatever.

If I recall correctly, core issue #9 clarifies the above is allowed,
though I forget if it's part of TC1 or not.

 

[Victor Bazarov]

If I recall correctly, core issue #9 clarifies the above is allowed,
though I forget if it's part of TC1 or not.

I am sorry, Greg, the statement seems ambiguous to me. What's allowed?
Are you saying that the difference in behaviour between Comeau C++ and
Visual C++ on the line marked "should be an error" in the code above is
something the Standard allows? How can it be an error and not an error
at the same time? Or are you referring to b.A::foo() way to circumvent
the access specifiers? No, I haven't checked out the core issue #9 (I
know I should, but where to get the time...)

Thank you.

Victor

P.S. I am sure the community at large truly appreciates that you (and
other lead specialists in the industry) take your time to read and reply
to messages here. It helps us tremendously to get through all complex
and murky issues associated with studying the language.