Board index » cppbuilder » Re: public, protected, private

Re: public, protected, private


2004-01-15 06:19:29 AM
cppbuilder39
"Thomas Maeder [TeamB]" < XXXX@XXXXX.COM >wrote in message news: XXXX@XXXXX.COM ...
Quote
"Duane Hebert" < XXXX@XXXXX.COM >writes:

Just a side note.

>int main() {
>Base B;
>B.Show();
>Derived *D = new Derived;
>Base *BPtr = reinterpret_cast<Base*>(D);

reinterpret_cast isn't appropriate here, since a D * is implicitly converted
to a B *, as in:
Yep, it's the same as saying Base *Bptr = new Derived;
 
 

Re:Re: public, protected, private

Hi!
Duane Hebert wrote:
Quote
>reinterpret_cast isn't appropriate here, since a D * is implicitly converted
>to a B *, as in:


Yep, it's the same as saying Base *Bptr = new Derived;
If you wanted to cast from Base* to Derived*,a reinterpret_cast would
not be appropriate either. When dealing with base and derived class
pointer you either need a dynamic_cast or a static_cast.
#include <iostream>
struct A { int i; };
struct B { int j; };
struct Dev : public A, public B
{};
int main()
{
Dev d;
d.i = 5; d.j = 6;
A *pa = &d; //implicit cast
B *pb = reinterpret_cast<B*>(pa); //bad
pb->j = 10;
std::cout << d.i << ", " << d.j << std::endl;
}
Frank
 

Re:Re: public, protected, private

Hi!
Duane Hebert wrote:
Quote
(if I understand your question) that you want to try creating a derived class
with a base class pointer and from that pointer call this method.
Like:
#include <iostream>
#include <conio.h>
struct Base
{
public:
virtual void SomeMethod() const
{
std::cout << "Base::SomeMethod" << std::endl;
}
};
struct Dev : public Base
{
protected:
//now protected
virtual void SomeMethod() const
{
std::cout << "Dev::SomeMethod" << std::endl;
}
};
int main()
{
Dev const d;
Base *const pb = &d;
d.SomeMethod(); //forbidden
pb->SomeMethod(); //permitted
getch();
return 0;
}
The permitted approach uses virtual dispatch just to call the method we
are not allowed to call.
It makes sense if you do the following:
struct Base
{
public:
virtual ~Base() {};
virtual void outputInfo() const =0;
};
struct Dev : public Base
//abstract class
{
protected:
//make me abstract
virtual char const* getName() const =0;
//cannot remove virtual
void SomeMethod() const
{
//printout info available in this class
std::cout << "I am " << getName() << std::endl;
}
};
struct DevDev : public Dev
{
public:
virtual void SomeMethod() const
{
//basic info first
Dev::SomeMethod();
//now our own stuff
std::cout << "State of i: " << i << std::endl;
}
int i;
};
int main()
{
DevDev d;
d.i = 4;
d.Dev::SomeMethod(); //forbidden
return 0;
}
Frank
 

{smallsort}

Re:Re: public, protected, private

"JunkMail" < XXXX@XXXXX.COM >writes:
Quote
>>Can they move a virtual method up on the hierachary?
>>Can they move a virtual method down on the hierachy?
>
>What do you mean by "move a virtual method"? Nothing moves.
A derived class can override a virtual function, but that does not
move it. That overrides the base implementation.
When you write a class, you can put your class's members in the
public, protected, or private section, however you want. This is
independant and unrelated to the visibility of anything in the base
class.
If you have a base class with a public virtual function, and a derived
class overrides it, making the derived version private, then that
means you can call the function on the base class, and not on the
derived class.
Since you usually call polymorphic functions on a base class (else,
why make them virtual?) it needs to be visible in the base class (or
called by something in the base class.)
Quote
class Base
{
public:
protected:
virtual SomeMethod();
private:
};
If some member function of base doesn't call SomeMethod(), then this is
a bad decision to do, because nobody else can call it on a base.
Quote
class MoveUpHierachary : public Base
{
public:
virtual SomeMethod();
protected:
private:
};
This means that you can only call SomeMethod on a derived class, since
it's public. There is no point in the function being virtual, since
you're already requiring that they use the most derived type, and not
call it using polymorphism.
It's common to make all virtual functions private, even in the base
class. Then, the base class offers a public inline function that
calls the private virtual function. The reason for this is that the
base class can guarantee to always know when the virtual function is
called, and can install pre- and post- hooks. If the virtual function
itself is public, and it gets overriden, then the base class has NO
possible way of ever knowing when it gets called, unless the derived
class explicitly notifies it somehow.
Note: a derived class CAN override a private virtual function in the
base class. It cannot *call* the function in the base class, but it
can still override the function.
--
Chris (TeamB);
 

Re:Re: public, protected, private

Quote
Note: a derived class CAN override a private virtual function in the
base class. It cannot *call* the function in the base class, but it
can still override the function.
But the virtual function in the derived class must be private no?
I think the OP wants to know if he can have a base class with
a private virtual function and in the derived class somehow
create the same function with public access.
From the way that he's saying "promote" etc. I think he's thinking
about in Delphi where a derived class can "promote" a protected
member function of the base class
by simply declaring the same function as public in the derived
class. I think this is a broken concept from a C++ perspective.
 

Re:Re: public, protected, private

"Duane Hebert" < XXXX@XXXXX.COM >wrote in message
Quote
But the virtual function in the derived class must be private no?
No. The override would simply act as a promotion, promoting the private
Base method to an accessible Descendant method.
Quote
I think the OP wants to know if he can have a base class
with a private virtual function and in the derived class
somehow create the same function with public access.
Yes, simply declare is as public when overriding it.
Quote
From the way that he's saying "promote" etc. I think he's
thinking about in Delphi where a derived class can "promote"
a protected member function of the base class by simply
declaring the same function as public in the derived class.
That is exactly what is done in C++ as well, as long as it is overriding the
Base method, not overloading it or hiding it (those are separate topics of
discussion).
Gambit
 

Re:Re: public, protected, private

Quote
That is exactly what is done in C++ as well, as long as it is overriding the
Base method, not overloading it or hiding it (those are separate topics of
discussion).
But I don't think he's asking about overriding it.
class Base {
virtual void Show() { std::cout << "Base called" << std::endl;}
};
class Derived :public Base {
public:
virtual void Show() { std::cout << "Derived called" << std::endl;}
};
int main( int argc, char * argv[] )
{
Derived d;
d.Show();
return 0;
}
This will print "derived called"
Sure you can do this but you're calling the derived function that's
overriding the one in the base class. You cannot grant public
access to the base class's private function.
You can't do
Base *ptr = new Derived;
ptr->Show();
You can also write a public function in the derived class
that uses the base class's function if it is protected.
class Base {
protected:
virtual void Show() { std::cout << "Base called" << std::endl;}
};
class Derived :public Base {
public:
virtual void Show() { Base::Show();}
};
Now d.Show(); will print Base called. But you are not exposing
the actual base protected function to any access higher than it
is.
You are not promoting the base function to anything. You're more
familliar with delphi than I am but I believe in delphi I can just
redeclare it in the derived class with public access and
not redefine it at all and a caller to the derived class can access
this. If I'm wrong, sorry.
At any rate, I've never heard of this as "promotion"
except in delphi help files. I think for most C++ people that I know, especially
those using OOD, the more private the better. Any idiom that allowed a user
to have access to my private data or functions via a derived class would be
broken IMO.
 

Re:Re: public, protected, private

"Duane Hebert" < XXXX@XXXXX.COM >wrote in message
Quote
Sure you can do this but you're calling the derived function
that's overriding the one in the base class. You cannot grant
public access to the base class's private function.
No, but if the base class calls its own private method, the descendant's
method will be called instead.
Gambit
 

Re:Re: public, protected, private

Quote
>Sure you can do this but you're calling the derived function
>that's overriding the one in the base class. You cannot grant
>public access to the base class's private function.

No, but if the base class calls its own private method, the descendant's
method will be called instead.
Exactly. The base class's private methods are still private. You've
just replaced them with one in the derived class. You can not use
a base class pointer to a derived class to access publicly the base
class's private members. This is what I think the OP was asking.
Maybe it's a matter of semantics but to me, overriding is a method of
replacing. This whole "promoting" idea seems incorrect and backwards.
At any rate, these discussions are great.
 

Re:Re: public, protected, private

Quote
At any rate, these discussions are great.
yes I have learned a lot...thanks for the discussion.
 

Re:Re: public, protected, private

"Duane Hebert" < XXXX@XXXXX.COM >writes:
Quote
>Note: a derived class CAN override a private virtual function in the
>base class. It cannot *call* the function in the base class, but it
>can still override the function.

But the virtual function in the derived class must be private no?

I think the OP wants to know if he can have a base class with
a private virtual function and in the derived class somehow
create the same function with public access.
You can. However, a public function in a derived class does not
change that it's private in the base. Thus:
class Base
{
private:
virtual ~Base() { }
virtual void foo() { }
};
class Derived : public Base
{
public:
virtual void foo() { }
};
int main()
{
Derived d;
Base * pbase = &d;
Derived * pder &d;
pbase->foo(); // error, inaccessible
pder->foo(); // ok, visible
}
Quote
From the way that he's saying "promote" etc. I think he's thinking
about in Delphi where a derived class can "promote" a protected
member function of the base class
by simply declaring the same function as public in the derived
class. I think this is a broken concept from a C++ perspective.
By "promote" (visibility) in C++, it only affects the hierarchy from
that point and farther down. It does not change anything "up." If
you have a base pointer nothing changes, but if you have a derived (or
further derived pointer) you can call it since it was promoted to
public in the derived class.
--
Chris (TeamB);
 

Re:Re: public, protected, private

"Duane Hebert" < XXXX@XXXXX.COM >writes:
Quote
At any rate, I've never heard of this as "promotion" except in
delphi help files. I think for most C++ people that I know,
especially those using OOD, the more private the better. Any idiom
that allowed a user to have access to my private data or functions
via a derived class would be broken IMO.
The main reason this is a usually a poor design is that when you're
working with virtual functions, usually you want to write everything
in terms of the base class, without any dependency on derived types.
If something is only visible in a derived type, and you have a base
pointer, you have to downcast your pointer in order to call it. That
means that code that should be dealing with abstract concepts have to
know about some specific implementation, a horrible thing to do to
code in terms of reusability.
And I agree, more private is better, provided that the data is not
required for other uses outside the class. (An ideal data structure
would have all data private, and offer a minimal interface that
permits all necessary operations on that data, without causing any
users to know or care how the data inside is actually represented.
Whenver some code knows the layout of another class, you are
handcuffing the author of that other class... modifications can
suddenly break other code that he doesn't even know about.
--
Chris (TeamB);