Changing access specifier for virtual function

[dragoncoder]

Consider the following code

#include <iostream>

class Base {
public:
virtual void say() { std::cout << "Base" << std::endl; }
};

class Derived: public base {
private:
void say() { std::cout << "Derived" << std::endl; }
};

int main() {
Derived d;
Base* b = &d;
b->say();
return 0;
}

Running this program produces following output.

$ ./a.out
Derived
$

I have 2 questions:
1. Is the above code legal ?
2. If the virtual function is private in Base, can I make it public in
Derived ?

Thanks

[Thomas Tutone]

dragoncoder wrote:

Consider the following code

#include <iostream>

class Base {
public:
virtual void say() { std::cout << "Base" << std::endl; }
};

class Derived: public base {
private:
void say() { std::cout << "Derived" << std::endl; }
};

int main() {
Derived d;
Base* b = &d;
b->say();
return 0;
}

Running this program produces following output.

$ ./a.out
Derived
$

I have 2 questions:
1. Is the above code legal ?
Yes. And an excellent example of poor coding practice.
2. If the virtual function is private in Base, can I make it public in
Derived ?

No. If it were private in Base, then Derived wouldn't inherit it.

Best regards,

Tom

[Victor Bazarov]

dragoncoder wrote:

Consider the following code

#include <iostream>

class Base {
public:
virtual void say() { std::cout << "Base" << std::endl; }
};

class Derived: public base {
You mean

class Derived: public Base {
private:
void say() { std::cout << "Derived" << std::endl; }
};

int main() {
Derived d;
Base* b = &d;
b->say();
return 0;
}

Running this program produces following output.

$ ./a.out
Derived
$

I have 2 questions:
1. Is the above code legal ?
Yes, absolutely, considering the correction I made. Try not to type your
code directly into the message next time. Use "copy-and-paste" mechanism
undoubtedly available to you.
2. If the virtual function is private in Base, can I make it public in
Derived ?

The access specifier only has effect on the ability to call the function
as if it weren't virtual. For example, if you make 'say' private in 'Base',
your call to it in 'main' (b->say()) will be ill-formed, and won't compile.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Victor Bazarov]

Thomas Tutone wrote:

dragoncoder wrote:

Consider the following code

#include <iostream>

class Base {
public:
virtual void say() { std::cout << "Base" << std::endl; }
};

class Derived: public base {
private:
void say() { std::cout << "Derived" << std::endl; }
};

int main() {
Derived d;
Base* b = &d;
b->say();
return 0;
}

Running this program produces following output.

$ ./a.out
Derived
$

I have 2 questions:
1. Is the above code legal ?

Yes. And an excellent example of poor coding practice.

Why do you call this practice "poor"?

2. If the virtual function is private in Base, can I make it public
in Derived ?

No. If it were private in Base, then Derived wouldn't inherit it.

Nothing is inherited here. It's _overridden_. Try it:

#include <iostream>

class Base {
virtual int foo() { return 42; } // private
public:
int bar() { return foo(); }
};

class Derived : public Base {
virtual int foo() { return 73; } // also private
};

int main()
{
Derived d;
Base *b = &d;
std::cout << b->bar() << std::endl;
return 0;
}

What happens here?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Tejas Kokje]

dragoncoder wrote:

Consider the following code

#include <iostream>

class Base {
public:
virtual void say() { std::cout << "Base" << std::endl; }
};

class Derived: public base {
private:
void say() { std::cout << "Derived" << std::endl; }
};

int main() {
Derived d;
Base* b = &d;
b->say();
return 0;
}

Running this program produces following output.

$ ./a.out
Derived
$

I have 2 questions:
1. Is the above code legal ?
Since the above code compiled, it is syntactically legal.
2. If the virtual function is private in Base, can I make it public in
Derived ?

The call to b->say() is calling Derived class say() function. Here
Derived class does not know anything about say() function of Base class
since say() is private in Base(). Hence say() functions in Derived and
Base class are not related by virtual function paradigm.

Even if you remove "virtual" specifier from Base class say() function,
you will still run Derived class say() function since say() is public
in Derived and there is no public say() in Base class.

Tejas Kokje

[Phlip]

Tejas Kokje wrote:

1. Is the above code legal ?

Since the above code compiled, it is syntactically legal.

Famous last words.

Try: "The code is well-formed, so it should compile."

Plenty of compilers reject plenty of well-formed constructions.

Yes, the OP is correct to rely on their compiler to judge how well such a
simple bit of code is formed!

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Tejas Kokje]

Phlip wrote:

Tejas Kokje wrote:

1. Is the above code legal ?
Since the above code compiled, it is syntactically legal.

Famous last words.

Try: "The code is well-formed, so it should compile."

Plenty of compilers reject plenty of well-formed constructions.
Yes, the OP is correct to rely on their compiler to judge how well such a
simple bit of code is formed!

I think you misunderstood my comments. I said that the code is
*syntactically* legal. This does not mean that code semantics make
sense. If compilers could detect semantic errors in code, most of the
softwares would be bug free.

Anyways, in OP's case, compiler did compile the code. So there is no
reason for him/her to see the code as illegal. However, OP is not
relying on compiler to tell him that code is well formed. Hence he/she
posted a question here.

Tejas Kokje

[Jakob Bieling]

Tejas Kokje <bi*************@gmail.com> wrote:

dragoncoder wrote:

Running this program produces following output.

$ ./a.out
Derived
$

I have 2 questions:
1. Is the above code legal ?

Since the above code compiled, it is syntactically legal.

No. Most compilers are broken in one respect or the other. I do not
know if Comeau is 100% compliant even. The code below will compile with
some compilers, but it is *not* syntactically legal:

class foo
{
void bar () {}
};

int main ()
{
void (foo::*pbar) () = foo::bar;
}
regards
--
jb

(reply address in rot13, unscramble first)

[Tejas Kokje]

Can you tell me which compiler compiles above code ?

since bar() is private and non-static to class foo, how can you access
it outside the class using class scope ?

Tejas Kokje

[Daniel T.]

In article <11**********************@g10g2000cwb.googlegroups .com>,
"dragoncoder" <pk******@gmail.com> wrote:

Consider the following code

#include <iostream>

class Base {
public:
virtual void say() { std::cout << "Base" << std::endl; }
};

class Derived: public base {
private:
void say() { std::cout << "Derived" << std::endl; }
};

int main() {
Derived d;
Base* b = &d;
b->say();
return 0;
}

Running this program produces following output.

$ ./a.out
Derived
$

I have 2 questions:
1. Is the above code legal ?
Absolutely. It's a great way to make sure the derived object is used
through a base pointer.

2. If the virtual function is private in Base, can I make it public in
Derived ?

Yes.
--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[Daniel T.]

In article <11*********************@i40g2000cwc.googlegroups. com>,
"Tejas Kokje" <bi*************@gmail.com> wrote:

Can you tell me which compiler compiles above code ?

since bar() is private and non-static to class foo, how can you access
it outside the class using class scope ?

One of the compilers I use will in fact compile the code despite the
fact that bar() is private and non-static to class foo.

It's used in NintendoDS development. It also can't handle exceptions or
the STL.
--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[Thomas Tutone]

Victor Bazarov wrote:

Thomas Tutone wrote:

dragoncoder wrote:
[snip]

class Base {
public:
virtual void say() { std::cout << "Base" << std::endl; }
};

class Derived: public base {
private:
void say() { std::cout << "Derived" << std::endl; }
}; I have 2 questions:
1. Is the above code legal ?

Yes. And an excellent example of poor coding practice.

Why do you call this practice "poor"?

Because it violates substitutability. Derived supposedly "is-a" Base,
and yet say() is no longer a public member function. See, for example,
[Cline et al., C++ FAQs (2nd Ed. 1999), FAQ 7.06 ("Is it proper to
revoke (hide) an inherited public member function?")].

2. If the virtual function is private in Base, can I make it public
in Derived ?

No. If it were private in Base, then Derived wouldn't inherit it.

Nothing is inherited here. It's _overridden_.

Yes, you're right - I confused my terminology. Thank you for the
correction.

Best regards,

Tom

[Victor Bazarov]

Thomas Tutone wrote:

Victor Bazarov wrote:

Thomas Tutone wrote:

dragoncoder wrote:
[snip]
class Base {
public:
virtual void say() { std::cout << "Base" << std::endl; }
};

class Derived: public base {
private:
void say() { std::cout << "Derived" << std::endl; }
}; I have 2 questions:
1. Is the above code legal ?

Yes. And an excellent example of poor coding practice.

Why do you call this practice "poor"?

Because it violates substitutability. Derived supposedly "is-a" Base,
and yet say() is no longer a public member function. See, for
example, [Cline et al., C++ FAQs (2nd Ed. 1999), FAQ 7.06 ("Is it
proper to revoke (hide) an inherited public member function?")].

I don't have that book, if you care to discuss issues brough up in it,
quote it, and we will know what you're talking about.

If the client (user) code only knows about the Base class (and only cares
about the Base class), changing the derived class' virtual members' access
specifiers (a) does not break the polymorphic behaviour and (b) prevents
accidental non-polymorphic use of those functions where a call to Base is
intended. The compiler does not make decisions to resolve the call based
on the access specifiers, but if it instead of intended use of Base member
attempts to use Derived's member, the privateness of the Derived's member
will cause the compiler to barf.

Besides, an even better practice would actually be to hide _both_ 'say'
members in the private area, define another, non-virtual function in Base
and make it call 'say':

class Base {
virtual void say();
public:
void talk() { say{}; }
};

In this case nobody should complain about changing the access levels of
the interface components.

V
--
Please remove capital As from my address when replying by mail

[Daniel T.]

In article <11**********************@j33g2000cwa.googlegroups .com>,
"Thomas Tutone" <Th***********@yahoo.com> wrote:

Victor Bazarov wrote:

Thomas Tutone wrote:

dragoncoder wrote:
[snip]
class Base {
> public:
> virtual void say() { std::cout << "Base" << std::endl; }
> };
>
> class Derived: public base {
> private:
> void say() { std::cout << "Derived" << std::endl; }
> }; I have 2 questions:
> 1. Is the above code legal ?

Yes. And an excellent example of poor coding practice.

Why do you call this practice "poor"?

Because it violates substitutability. Derived supposedly "is-a" Base,
and yet say() is no longer a public member function. See, for example,
[Cline et al., C++ FAQs (2nd Ed. 1999), FAQ 7.06 ("Is it proper to
revoke (hide) an inherited public member function?")].

also at
<http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.1>
Attempting to hide (eliminate, revoke, privatize) inherited public
member functions is an all-too-common design error. It usually stems
from muddy thinking.

In the above code, Derived does not eliminate, revoke or privatize
anything. Any user of Derived can still call the 'say' function (by
using a Base*.)

Unfortunately, Cline doesn't give an example of what he means (either on
the website or in the book.)
--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.