private member function or non-member utility function

Discussion in 'C++' started by ittium, Dec 23, 2011.

  1. ittium

    ittium Guest

    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, Dec 23, 2011
    #1
    1. Advertising

  2. 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.)
    Juha Nieminen, Dec 23, 2011
    #2
    1. Advertising

  3. ittium

    ittium Guest

    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, Dec 24, 2011
    #3
  4. 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.
    Juha Nieminen, Dec 24, 2011
    #4
  5. On Dec 23, 4:47 pm, 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.


    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, Dec 28, 2011
    #5
  6. Nick Keighleyæ–¼ 2011å¹´12月28日星期三UTC+8下åˆ8時30分50秒寫é“:
    > On Dec 23, 4:47 pm, 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.

    >
    > 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.
    88888 Dihedral, Jan 12, 2012
    #6
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. slide_o_mix
    Replies:
    0
    Views:
    410
    slide_o_mix
    Oct 15, 2003
  2. Alex
    Replies:
    0
    Views:
    380
  3. puzzlecracker
    Replies:
    2
    Views:
    461
    Daniel Pitts
    Jul 25, 2008
  4. Peng Yu
    Replies:
    3
    Views:
    1,067
    Simon Forman
    Sep 21, 2009
  5. Gregor Kofler
    Replies:
    6
    Views:
    205
    Gregor Kofler
    Jun 27, 2008
Loading...

Share This Page