private member functions

[David Rubin]

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

 

[Ali R.]

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]

[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

 

[jeffc]

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?

 

[lilburne]

:



[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.

 

[Jerry Coffin]

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.