Private functions

  • Thread starter Chris P. Stubbs
  • Start date
C

Chris P. Stubbs

Hello All

I have a base class called Action_Request, and a set of classes
corresponding to different kinds of Action_Request, each of which inherits
from Action_Request. Eg:-

class Add_Molecule_Req: public Action_Request{
// ......

};

I manipulate the various derived classes polymorphically through
Action_Requests's public interface, using its virtual functions.
Currently the overriding functions in the derived classes (including the
destructor, which overrides Action_Request's virtual destructor), are
declared public.

My program compiles if I make them private, and doing this would seem to
have the advantage that these functions must then always be invoked
polymorphically through Action_Request's public interface, which is what I
want.

My questions are:-

i) Is overriding public virtual functions with private functions good
practice?
ii) Are there any disadvantages?

Best - CPS
 
K

Keith Thompson

Chris P. Stubbs said:
I have a base class called Action_Request, and a set of classes
corresponding to different kinds of Action_Request, each of which inherits
from Action_Request. Eg:-
[...]

comp.lang.c++ is down the hall to the left, just past the water
cooler.
 
K

Kenny McCormack

Chris P. Stubbs said:
I have a base class called Action_Request, and a set of classes
corresponding to different kinds of Action_Request, each of which inherits
from Action_Request. Eg:-
[...]

comp.lang.c++ is down the hall to the left, just past the water
cooler.

This line was funny/clever the first 1,000,000 times it was used.

But that time has passed.
 
S

Sjouke Burry

Kenny said:
Chris P. Stubbs said:
I have a base class called Action_Request, and a set of classes
corresponding to different kinds of Action_Request, each of which inherits
from Action_Request. Eg:-
[...]

comp.lang.c++ is down the hall to the left, just past the water
cooler.

This line was funny/clever the first 1,000,000 times it was used.

But that time has passed.
Know a better way to discourage the C++ brats to degrade
this newsgroup??
 
K

Kaz Kylheku

Chris P. Stubbs said:
I have a base class called Action_Request, and a set of classes
corresponding to different kinds of Action_Request, each of which inherits
from Action_Request. Eg:-
[...]

comp.lang.c++ is down the hall to the left, just past the water
cooler.

Ah, common mistake. That's actually a stapler designed by the
ISO C++ committee.
 
K

Kaz Kylheku

Chris P. Stubbs said:
I have a base class called Action_Request, and a set of classes
corresponding to different kinds of Action_Request, each of which inherits
from Action_Request. Eg:-
[...]

comp.lang.c++ is down the hall to the left, just past the water
cooler.

Ah, common mistake. That's actually a stapler designed by the
ISO C++ committee.

And I will have you know that it integrates some new ... concepts.
 
K

Kenny McCormack

Kenny said:
I have a base class called Action_Request, and a set of classes
corresponding to different kinds of Action_Request, each of which inherits
from Action_Request. Eg:-
[...]

comp.lang.c++ is down the hall to the left, just past the water
cooler.

This line was funny/clever the first 1,000,000 times it was used.

But that time has passed.
Know a better way to discourage the C++ brats to degrade
this newsgroup??

I suspect that its innate cuteness and cleverness is lost on the
non-native-English-speakers crowd anyway. I.e., those who post it
aren't really helping the posters much - but rather showing each other
how clever they are.
 
N

Nick Keighley

Know a better way to discourage the C++ brats to degrade
this newsgroup??

oh, and it's rude to refer to someone as a brat becuse they are
unclear on the differences between C and C++
 
C

Chris P. Stubbs

Thanks for this - interesting. As I understand it, the Liskov Substitution
Principle (LSP) is about maintaining the "is a" relationship between the
derived class and the base class. What I am trying to do is to use the base
class to provide a common interface to a set of classes that can be used
polymorphically. Does the LSP apply in this case?

Best - CPS

Chris said:
[...]
i) Is overriding public virtual functions with private functions good
practice?
ii) Are there any disadvantages?

http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.1
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.4

By the way, this question belongs to comp.lang.c++
 
K

Keith Thompson

Chris P. Stubbs said:
Chris said:
[...]
i) Is overriding public virtual functions with private functions good
practice?
ii) Are there any disadvantages?

http://www.parashift.com/c++-faq-lite/proper-inheritance.html#faq-21.1
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.4

By the way, this question belongs to comp.lang.c++

Thanks for this - interesting. As I understand it, the Liskov Substitution
Principle (LSP) is about maintaining the "is a" relationship between the
derived class and the base class. What I am trying to do is to use the base
class to provide a common interface to a set of classes that can be used
polymorphically. Does the LSP apply in this case?

Why are you asking here? This is comp.lang.c. The C++ experts who
can answer your question are in comp.lang.c++. (They probably don't
like top-posting either.)

I'd cross-post and redirect followups, but that only works if everyone
posts followups to this article. Start a new thread in comp.lang.c++.
 
N

Nick Keighley

x-posted to comp.lang.c,comp.lang.c++,comp.object

hello!!


Why are you asking here?  This is comp.lang.c.  The C++ experts who
can answer your question are in comp.lang.c++.  (They probably don't
like top-posting either.)

there's comp.object as well
 
K

Keith Thompson

Nick Keighley said:
x-posted to comp.lang.c,comp.lang.c++,comp.object

Which guarantees, since you didn't redirect followups, that at least
part of this thread will continue in comp.lang.c. Nice work.

I've redirected followups to alt.dev.null; if you want to post a
followup to *this* article, you'll need to adjust the headers.
 
R

Rui Maciel

Malcolm McLean wrote:

The emerging consensus is that object-orientation makes programs brittle,
hard to modify, and hard to follow. That's what some of us C people have
been saying for years. Finally people are beginning to listen. However
the debate is by no means over yet.

How does object-orientation make programs hard to modify or read?


Rui Maciel
 
K

Kenny McCormack

Which guarantees, since you didn't redirect followups, that at least
part of this thread will continue in comp.lang.c. Nice work.

I've redirected followups to alt.dev.null; if you want to post a
followup to *this* article, you'll need to adjust the headers.

What do I win?
 
N

Nobody

How does object-orientation make programs hard to modify or read?

Because figuring out what something as simple-looking as "a=b;" actually
*does* can require an epic journey through the source code for a hundred
different classes.

In C, function calls look like function calls (so long as you don't abuse
the pre-processor). In C++, almost anything can be a function call (and
I'm not all that sure about the "almost" part).

And while a single function call in C *might* involve a trip through a
hundred different functions, the nature of C++ is such that it probably
will involve such a trip.

OO is fine so long as your abstractions are perfect, or at least 100%
adequate for the task. But as soon as the adequacy drops to 99.9%, you
have to take a look at the mess behind the curtain.

Hiding messy details is fine, right up until the point that the details
actually matter. At that point, all of the hiding makes life harder rather
than easier.
 
U

user923005

Malcolm McLean wrote:



How does object-orientation make programs hard to modify or read?

Generally, the problems come from abuse of the language, but some are
also natural outcomes.

Something that is a natural consequence of inheritance:
For instance, if there is a long chain of inheritance, then a subtle
modification of behavior in a base class can have all sorts of
profoundly weird alterations of the final class. This is usually
referred to as "the house of cards" by people I work with.

Things that come from poor coding include things like:
1. Over use of references that are not const references (changing the
contents in the caller).
2. Operator overloads that are not obvious in meaning or that have
wrong precedence in the context of actual use (e.g. overloading ** to
mean exponentiation).

These are just the consequence of lazy programming and can easily be
avoided.

Of course, for every C++ drawback, we can probably find an equal C
drawback.

For most data structures and algorithms, I greatly prefer C++ because
of templates. However, I often use C when I need to write a simple
filter in a hurry.

The biggest downside of C++ {compared to C} is also one of its biggest
upsides. The language is titanically huge in comparison with C. To
fully learn and understand C++ is far more difficult. However, once
you *have* leared it, you have STL, Boost, etc. at your beck and
call. So in that context, the gargantuan size is a benefit and not a
detriment.

All in all, there are definitely projects when one or the other is a
more logical choice (primarily determined by what programming
resources are available and their skill sets and secondarily
determined by the nature of the projects).

As usual, we can expect this thread to degerate into a flame-fest, as
all "my language/OS/Editor..." is better than yours threads always do.

IMO-YMMV.
 
A

Antoninus Twink

I've redirected followups to alt.dev.null; if you want to post a
followup to *this* article, you'll need to adjust the headers.

Done.

Why don't you get over yourself, Keith? The OP's question was /not/
specific to C++. It was a general question about OO programming, which
can equally well be done in C. Why try to force people who do OO
programming in C to subscribe to another group to get an answer to a
question they might find interesting?

Idiot.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,994
Messages
2,570,223
Members
46,813
Latest member
lawrwtwinkle111

Latest Threads

Top