«

Group,
How to decide whether a procedure should be private member function or
non-member utility function. In my opinion if a function does not
specify a class interface but can change "this pointer", it should be
declared as private, if it does not change "this pointer", it should be
defined as non-class utility function or static function of some utility
class.
thanks
Ittium

ittium <> wrote:
> How to decide whether a procedure should be private member function or
> non-member utility function. In my opinion if a function does not
> specify a class interface but can change "this pointer", it should be
> declared as private, if it does not change "this pointer", it should be
> defined as non-class utility function or static function of some utility
> class.

There's, obviously, a big difference in accessibility between a private
method and a free function. The latter is accessible from anywhere while
the former isn't.

Also, in the latter case if the function needs to access the private
section of the class, you'll have to declare it as a friend. This can
pose some problems if you would want to make the free function local to
the compilation unit rather than making it global. (Actually, I don't even
know if you can declare a local function a friend of a class. I have never
even tried it. Even if you can, I'm sure this would cause some ambiguity
problems because there's no syntax to specify *which* compilation unit we
are talking about.)

On 23-12-2011 PM 10:17, Juha Nieminen wrote:
> ittium<> wrote:
>> How to decide whether a procedure should be private member function or
>> non-member utility function. In my opinion if a function does not
>> specify a class interface but can change "this pointer", it should be
>> declared as private, if it does not change "this pointer", it should be
>> defined as non-class utility function or static function of some utility
>> class.
>
> There's, obviously, a big difference in accessibility between a private
> method and a free function. The latter is accessible from anywhere while
> the former isn't.

yes, absolutely.

>
> Also, in the latter case if the function needs to access the private
> section of the class, you'll have to declare it as a friend.

If it accesses private data, I would also make it private.

The function is not supposed to access the private data but doing some
processing that is helping the class e.g. suppose this function do some
mathematical calculation (relevant to this class) but do not modify
*this. Other function in the class will call this method as a helper
method.

> This can
> pose some problems if you would want to make the free function local to
> the compilation unit rather than making it global.

I can define the function in a header file that can be included the
header file where class is defined. Function will be compiled in some
utility library that can be linked during linking procedure.


(Actually, I don't even
> know if you can declare a local function a friend of a class. I have never
> even tried it. Even if you can, I'm sure this would cause some ambiguity
> problems because there's no syntax to specify *which* compilation unit we
> are talking about.)

ittium <> wrote:
>> This can
>> pose some problems if you would want to make the free function local to
>> the compilation unit rather than making it global.
>
> I can define the function in a header file that can be included the
> header file where class is defined. Function will be compiled in some
> utility library that can be linked during linking procedure.

That doesn't make it any less global.

On Dec 23, 4:47*pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> ittium <itt...@gmail.com> wrote:
> > How to decide whether a procedure should be private member function or
> > non-member utility function. In my opinion if a function does not
> > specify a class interface but can change "this pointer", it should be
> > declared as private, if it does not change "this pointer", it should be
> > defined as non-class utility function or static function of some utility
> > class.
>
> * There's, obviously, a big difference in accessibility between a private
> method and a free function. The latter is accessible from anywhere while
> the former isn't.

not if you make it static

> * Also, in the latter case if the function needs to access the private
> section of the class, you'll have to declare it as a friend. This can
> pose some problems if you would want to make the free function local to
> the compilation unit rather than making it global. (Actually, I don't even
> know if you can declare a local function a friend of a class. I have never
> even tried it. Even if you can, I'm sure this would cause some ambiguity
> problems because there's no syntax to specify *which* compilation unit we
> are talking about.)

Nick Keighleyæ–¼ 2011å¹´12月28日星期三UTC+8下å�ˆ8時30分50ç§ ’寫é�“：
> On Dec 23, 4:47Â*pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> > ittium <itt...@gmail.com> wrote:
> > > How to decide whether a procedure should be private member function or
> > > non-member utility function. In my opinion if a function does not
> > > specify a class interface but can change "this pointer", it should be
> > > declared as private, if it does not change "this pointer", it should be
> > > defined as non-class utility function or static function of some utility
> > > class.
> >
> > Â* There's, obviously, a big difference in accessibility between a private
> > method and a free function. The latter is accessible from anywhere while
> > the former isn't.
>
> not if you make it static
>
> > Â* Also, in the latter case if the function needs to access the private
> > section of the class, you'll have to declare it as a friend. This can
> > pose some problems if you would want to make the free function local to
> > the compilation unit rather than making it global. (Actually, I don't even
> > know if you can declare a local function a friend of a class. I have never
> > even tried it. Even if you can, I'm sure this would cause some ambiguity
> > problems because there's no syntax to specify *which* compilation unit we
> > are talking about.)

The private or public checking in the compile time does not matter too much..

Anyway the compile time is not the execution run time.

In higher level languages the read/write spec means more overheads in the
interpreters in the run time.