Please consider the following code:
class Abstract
{
public:
virtual ~Abstract() {}
virtual void Method() = 0;
};
class Concrete : public virtual Abstract
{
private:
virtual void Method() {}
};
void UseAbstract()
{
Concrete concrete;
Abstract& abstract = concrete;
abstract.Method();
}
The implementation for Abstract::Method provided in the Concrete class
is private even though the declaration of the method is public in the
derived base class. Yet, compiling the code on three different
compilers produces no errors or warnings. I think many developer might
find this surprising and puzzling. I, myself, am not sure what to
think of it.
The end effect is that the implementation for the Abstract class works
as expected. An instance of Concrete can be used as an Abstract
instance and it works as expected with respect to the Abstract
interface. Method is public for Abstract and can be accessed just
fine, even though it is private with respect to its Concrete
implementation.
However, it seems that there is something wrong, or at least worrisome
about the fact that this can be done.
What can people say about the correctness of this code?
If it is correct, what are the reasons classes are allow to behave this
way? 7 1886
<tr*********@verizon.net> wrote in message
news:11**********************@t39g2000cwt.googlegr oups.com Please consider the following code:
class Abstract { public: virtual ~Abstract() {} virtual void Method() = 0; };
class Concrete : public virtual Abstract { private: virtual void Method() {} };
void UseAbstract() { Concrete concrete; Abstract& abstract = concrete;
abstract.Method(); }
The implementation for Abstract::Method provided in the Concrete class is private even though the declaration of the method is public in the derived base class. Yet, compiling the code on three different compilers produces no errors or warnings. I think many developer might find this surprising and puzzling. I, myself, am not sure what to think of it.
What object a reference refers to cannot always be known at compile time but
may instead only be known at run time. Access rules are enforced at compile
time, so access rules cannot depend on the object referred to. Instead, they
depend on the type of the reference, since this is known at compile time.
The type of abstract is "reference to Abstract" and Method() is public in
Abstract. Accordingly, access must be allowed.
--
John Carson
John Carson wrote: What object a reference refers to cannot always be known at compile time but may instead only be known at run time. Access rules are enforced at compile time, so access rules cannot depend on the object referred to. Instead, they depend on the type of the reference, since this is known at compile time. The type of abstract is "reference to Abstract" and Method() is public in Abstract. Accordingly, access must be allowed.
-- John Carson
Thanks John. That makes sense.
On 2006-02-26, tr*********@verizon.net <tr*********@verizon.net> wrote: Please consider the following code:
class Abstract { public: virtual ~Abstract() {} virtual void Method() = 0; };
class Concrete : public virtual Abstract { private: virtual void Method() {} };
void UseAbstract() { Concrete concrete; Abstract& abstract = concrete;
abstract.Method(); }
The implementation for Abstract::Method provided in the Concrete class is private even though the declaration of the method is public in the derived base class. Yet, compiling the code on three different compilers produces no errors or warnings. I think many developer might find this surprising and puzzling. I, myself, am not sure what to think of it.
It is this way because the alternative seemed worse. The C++ designers
deemed it would be horrible if changing the access specification of a
member function somewhere in your class hierarchy could alter the
resolution of a virtual function call, or cause your program to no
longer compile. Consider multiple inheritance:
class B {
public:
virtual void foo();
};
class X: public B {
private:
void foo();
};
class Y: public B {
public:
void foo();
};
class Fubar: public X, Y {
public:
void foo();
};
In this hierarchy, under a rule that made the private foo in X
inaccessible, there would be no ambiguity in the following call in
function fnagn. It would have to resolve to the public override in B.
void fnagn(Fubar* f)
{
f->foo();
}
But if the access specification of foo in X were then changed to
public, suddenly your code would not even compile.
So the actual rules make your code more robust, in theory. The call to
foo in fnagn is ambiguous, despite foo in X being private.
--
Neil Cerutti
Neil Cerutti wrote: But if the access specification of foo in X were then changed to public, suddenly your code would not even compile.
The other odious alternative enforces access at runtime. That would add
extra opcodes to all the virtual functions that don't need them.
The OP should research Design Patterns. Sometimes a method's access is a
valid technique.
--
Phlip http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
Phlip wrote: Neil Cerutti wrote:
But if the access specification of foo in X were then changed to public, suddenly your code would not even compile. The other odious alternative enforces access at runtime. That would add extra opcodes to all the virtual functions that don't need them.
The OP should research Design Patterns. Sometimes
changing!
a method's access is a valid technique.
--
Phlip http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
On 2006-02-27, Neil Cerutti <le*******@email.com> wrote: On 2006-02-26, tr*********@verizon.net <tr*********@verizon.net> wrote: It is this way because the alternative seemed worse. The C++ designers deemed it would be horrible if changing the access specification of a member function somewhere in your class hierarchy could alter the resolution of a virtual function call, or cause your program to no longer compile. Consider multiple inheritance:
class B { public: virtual void foo(); };
class X: public B { private: void foo(); };
class Y: public B { public: void foo(); };
class Fubar: public X, Y { public: void foo(); };
In this hierarchy, under a rule that made the private foo in X inaccessible, there would be no ambiguity in the following call in function fnagn. It would have to resolve to the public override in B.
void fnagn(Fubar* f) { f->foo(); }
It seems people got the point, but there were errors in my example code.
Fubar should not declare a function foo, and fnagn should receive
pointer to B.
But if the access specification of foo in X were then changed to public, suddenly your code would not even compile.
So the actual rules make your code more robust, in theory. The call to foo in fnagn is ambiguous, despite foo in X being private.
--
Neil Cerutti
You can't give him that cutback lane. He's so fast, and he sees
it so well. He can also run away from you if he gets a little
bit of crack. --Dick Lebeau tr*********@verizon.net wrote: Please consider the following code:
class Abstract { public: virtual ~Abstract() {} virtual void Method() = 0; };
class Concrete : public virtual Abstract { private: virtual void Method() {} };
void UseAbstract() { Concrete concrete; Abstract& abstract = concrete;
abstract.Method(); }
The implementation for Abstract::Method provided in the Concrete class is private even though the declaration of the method is public in the derived base class. Yet, compiling the code on three different compilers produces no errors or warnings. I think many developer might find this surprising and puzzling. I, myself, am not sure what to think of it.
The end effect is that the implementation for the Abstract class works as expected. An instance of Concrete can be used as an Abstract instance and it works as expected with respect to the Abstract interface. Method is public for Abstract and can be accessed just fine, even though it is private with respect to its Concrete implementation.
However, it seems that there is something wrong, or at least worrisome about the fact that this can be done.
What can people say about the correctness of this code? If it is correct, what are the reasons classes are allow to behave this way?
The rule of thumb is that only the names of things can be made private,
not the things themselves. I think the main reason for this is that
it's
not possible at (least currently) to have ironclad protection of
members
that could not be defeated with casts, and have no run-time overhead.
In the particular example you give, I think there are cases where it
could actually be useful. The purpose of private is for the designer
of the class to prevent class users from creating undesired
dependencies
on cretain specifics of the class definition. What the above code is
saying is "don't write any code for Concrete instances using 'method()'
that would not also work for all instances of Abstract". This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: vijay |
last post by:
Hello
I wanted to understand a contradictory design of C++
class A
{public:
virtual void f(){ cout<<" base f"<<endl; }
};
class B:public A
{
|
by: Dave |
last post by:
Hello all,
Suppose that derived inherits privately from base. A base pointer may not
be made to point at a derived object in this case. I understand that is
exactly what is supposed to happen...
|
by: Anon Email |
last post by:
Hi people,
I'm learning about header files in C++. The following is code from
Bartosz Milewski:
// Code
const int maxStack = 16;
class IStack
|
by: Manolis |
last post by:
Hi,
I was wondering if there is any way to make two objects of the same
class to be able to access each other's private data, like this:
class A {
public:
void access( const A& a )...
|
by: Noah Coad [MVP .NET/C#] |
last post by:
How do you make a member of a class mandatory to override with a _new_
definition? For example, when inheriting from
System.Collections.CollectionBase, you are required to implement certain...
|
by: Joel |
last post by:
Why does this work:
using System;
namespace ConsoleApplication1
{
class Class1
{
static void Main(string args)
|
by: jopperdepopper |
last post by:
Hi,
finally giving php 5 a go, and going over the new approach to classes.
Can someone clarify the public, private and protected to me?
I quote the php manual: "The visibility of a property or...
|
by: John Goche |
last post by:
Hello,
page 202 of Symbian OS Explained by Jo Stichbury states
"All virtual functions, public, protected or private, should be
exported"
then page 203 states
"In the rare cases where a...
|
by: v4vijayakumar |
last post by:
Why we need "virtual private member functions"? Why it is not an
(compile time) error?
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |