By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,002 Members | 1,269 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,002 IT Pros & Developers. It's quick & easy.

private member functions

P: n/a
Is there ever a good reason to declare private non-virtual member
functions in a class definition?

As far as private virtual function are concerned, my understanding is
that, if you have a (public) function which calls an private virtual
function in the base class, the behavior can be changed by overriding
the private virtual function in the derived class (but leaving the
calling function unchanged). This at least seems useful.

/david

--
Andre, a simple peasant, had only one thing on his mind as he crept
along the East wall: 'Andre, creep... Andre, creep... Andre, creep.'
-- unknown
Jul 19 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
That all depends. and it's most a matter of preference.
One example that comes to mine is:
lets say that you have methods A and B which do something that are kinda
similar, methods could be virtual or may not besides the point. so you as a
good programmer will isolate the similarities and put in method C. Now
calling method C out of context could be disasterus and also no one other
than this on class will ever use it. If it was me, it would be a private
method. You might say why not protected, I guess there is still a danger of
someone using it in a derived class.

Ali R.

"David Rubin" <bo***********@nomail.com> wrote in message
news:3F***************@nomail.com...
Is there ever a good reason to declare private non-virtual member
functions in a class definition?

As far as private virtual function are concerned, my understanding is
that, if you have a (public) function which calls an private virtual
function in the base class, the behavior can be changed by overriding
the private virtual function in the derived class (but leaving the
calling function unchanged). This at least seems useful.

/david

--
Andre, a simple peasant, had only one thing on his mind as he crept
along the East wall: 'Andre, creep... Andre, creep... Andre, creep.'
-- unknown

Jul 19 '05 #2

P: n/a
"Ali R." wrote:
"David Rubin" <bo***********@nomail.com> wrote in message
news:3F***************@nomail.com...
Is there ever a good reason to declare private non-virtual member
functions in a class definition?

[snip - top-posting fixed] lets say that you have methods A and B which do something that are kinda
similar, methods could be virtual or may not besides the point. so you as a
good programmer will isolate the similarities and put in method C.


What I was really after was whether to declare a non-virtual private
method in the class interface or to declare a static function in the
implementation translation unit. I guess the major difference is that a
member function knows about the calling instance, and has access to
other private data. So, it depends on what the function does.

Thanks,

/david

--
Andre, a simple peasant, had only one thing on his mind as he crept
along the East wall: 'Andre, creep... Andre, creep... Andre, creep.'
-- unknown
Jul 19 '05 #3

P: n/a

"David Rubin" <bo***********@nomail.com> wrote in message
news:3F***************@nomail.com...

What I was really after was whether to declare a non-virtual private
method in the class interface or to declare a static function in the
implementation translation unit. I guess the major difference is that a
member function knows about the calling instance, and has access to
other private data. So, it depends on what the function does.


Certainly. Your question is a little confusing. What issue are you
concerned about? Non-virtual? Static? Private function? Private data?
Do you have a specific example in mind?
Jul 19 '05 #4

P: n/a
David Rubin wrote:
"Ali R." wrote:

"David Rubin" <bo***********@nomail.com> wrote in message
news:3F***************@nomail.com...
Is there ever a good reason to declare private non-virtual member
functions in a class definition?

[snip - top-posting fixed]
lets say that you have methods A and B which do something that are kinda
similar, methods could be virtual or may not besides the point. so you as a
good programmer will isolate the similarities and put in method C.

What I was really after was whether to declare a non-virtual private
method in the class interface or to declare a static function in the
implementation translation unit. I guess the major difference is that a
member function knows about the calling instance, and has access to
other private data. So, it depends on what the function does.


I don't like adding private member functions to a class. In
my experience private methods are usually either internal
implementation details, helper methods for the class, or
encapsulate some common code and I don't think this sort of
stuff belongs in the class header.

Personally I'd consider creating an auxillary class for
those private methods. It keeps the implementation details
out of the primary classes interface, so you can fiddle
about with it without causing client code to recompile, and
frequently the 'private methods' are actually useful outside
of the class anyway. In a large system you can often find
that a method you are about to write is already lurking
around as some private method in some obscure class.

In some cases though a private method makes sense, for
example if the method is making non-trivial usage of the
classes internal data, but I'd consider the auxillary class
first.

Jul 19 '05 #5

P: n/a
In article <3F***************@nomail.com>, bo***********@nomail.com
says...
Is there ever a good reason to declare private non-virtual member
functions in a class definition?
Yes -- semi-regularly, AAMOF (YYMV, of course). One that comes up
fairly frequently is having a ctor that you'd like to have call another.
Unfortunately, that doesn't work; the usual cure is to write a private
function for use by both ctors.
As far as private virtual function are concerned, my understanding is
that, if you have a (public) function which calls an private virtual
function in the base class, the behavior can be changed by overriding
the private virtual function in the derived class (but leaving the
calling function unchanged). This at least seems useful.


It is. Just FWIW, the function is often a friend, and frequently an
overloaded operator.

--
Later,
Jerry.

The universe is a figment of its own imagination.
Jul 19 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.