Use Function Pointer Instead Friend?

Discussion in 'C++' started by Immortal Nephi, Jul 6, 2008.

  1. I design a class for general purpose. I do not allow a client to read
    or modify interface and implemention. I allow them to write a new non-
    member function outside of class' interface and implmention. The
    problem is that non-member function cannot access private data member.

    The friend keyword is not the solution. I am aware that friend
    keyword allows the non-member function to access private data member.

    If you define more than two non-member functions, you will want one of
    some non-member function to be pointed to the member function pointer
    at run-time. The client can decide to remove first non-member
    function from the member function pointer and add another non-member
    function at run-time. The member function pointer array is not
    necessary according to my design.

    Does it mean that it is the only solution to access public data member
    only?

    Take a look at my example code below.

    #ifndef A_H
    #define A_H

    class A
    {
    public:
    typedef void (*Func_Ptr)(A &);

    A(void);
    ~A(void);

    void Run(void);
    void Set_Func_Ptr(Func_Ptr);

    private:
    friend void Non_Member_Func(A &);

    Func_Ptr Member_Func_Ptr;

    public:
    int W;
    int X;

    private:
    int Y;
    int Z;
    };

    #endif // A_H

    // A_CPP
    #include "A.h"

    A::A(void)
    {
    W = 1;
    X = 2;
    Y = 3;
    Z = 4;
    }

    A::~A(void)
    {
    }

    void A::Run(void)
    {
    Non_Member_Func( *this );
    Member_Func_Ptr( *this );
    }

    void A::Set_Func_Ptr(Func_Ptr Ptr)
    {
    Member_Func_Ptr = Ptr;
    }

    // MAIN_CPP
    #include <stdio.h>
    #include "A.h"

    void Non_Member_Func(A &a)
    {
    a.W *= 2; // Can access public
    a.X *= 2; // can access public
    a.Y *= 2; // can access private
    a.Z *= 2; // can access private

    printf("W: %d\nX: %d\nY: %d\nZ: %d\n", a.W, a.X, a.Y, a.Z);
    }

    void Member_Func(A &a)
    {
    a.W *= 2;
    a.X *= 2;

    // a.Y += 4; // Error can't access private
    // a.Z += 6; // Error can't access private

    printf("W: %d\nX: %d\n", a.W, a.X);
    }

    void Member_Func2(A &a)
    {
    a.W *= 4;
    a.X *= 4;

    // a.Y += 4; // Error can't access private
    // a.Z += 6; // Error can't access private

    printf("W: %d\nX: %d\n", a.W, a.X);
    }

    int main(void)
    {
    A a;

    Non_Member_Func( a );

    a.Set_Func_Ptr( Member_Func );
    a.Run();

    a.Set_Func_Ptr( Member_Func2) ;
    a.Run();

    return 0;
    }
     
    Immortal Nephi, Jul 6, 2008
    #1
    1. Advertising

  2. Immortal Nephi

    HL Guest

    On 7ÔÂ6ÈÕ, ÉÏÎç7ʱ38·Ö, Immortal Nephi <> wrote:
    > I design a class for general purpose. I do not allow a client to read
    > or modify interface and implemention. I allow them to write a new non-
    > member function outside of class' interface and implmention. The
    > problem is that non-member function cannot access private data member.
    >
    > The friend keyword is not the solution. I am aware that friend
    > keyword allows the non-member function to access private data member.
    >
    > If you define more than two non-member functions, you will want one of
    > some non-member function to be pointed to the member function pointer
    > at run-time. The client can decide to remove first non-member
    > function from the member function pointer and add another non-member
    > function at run-time. The member function pointer array is not
    > necessary according to my design.
    >
    > Does it mean that it is the only solution to access public data member
    > only?
    >
    > Take a look at my example code below.
    >
    > #ifndef A_H
    > #define A_H
    >
    > class A
    > {
    > public:
    > typedef void (*Func_Ptr)(A &);
    >
    > A(void);
    > ~A(void);
    >
    > void Run(void);
    > void Set_Func_Ptr(Func_Ptr);
    >
    > private:
    > friend void Non_Member_Func(A &);
    >
    > Func_Ptr Member_Func_Ptr;
    >
    > public:
    > int W;
    > int X;
    >
    > private:
    > int Y;
    > int Z;
    >
    > };
    >
    > #endif // A_H
    >
    > // A_CPP
    > #include "A.h"
    >
    > A::A(void)
    > {
    > W = 1;
    > X = 2;
    > Y = 3;
    > Z = 4;
    >
    > }
    >
    > A::~A(void)
    > {
    >
    > }
    >
    > void A::Run(void)
    > {
    > Non_Member_Func( *this );
    > Member_Func_Ptr( *this );
    >
    > }
    >
    > void A::Set_Func_Ptr(Func_Ptr Ptr)
    > {
    > Member_Func_Ptr = Ptr;
    >
    > }
    >
    > // MAIN_CPP
    > #include <stdio.h>
    > #include "A.h"
    >
    > void Non_Member_Func(A &a)
    > {
    > a.W *= 2; // Can access public
    > a.X *= 2; // can access public
    > a.Y *= 2; // can access private
    > a.Z *= 2; // can access private
    >
    > printf("W: %d\nX: %d\nY: %d\nZ: %d\n", a.W, a.X, a.Y, a.Z);
    >
    > }
    >
    > void Member_Func(A &a)
    > {
    > a.W *= 2;
    > a.X *= 2;
    >
    > // a.Y += 4; // Error can't access private
    > // a.Z += 6; // Error can't access private
    >
    > printf("W: %d\nX: %d\n", a.W, a.X);
    >
    > }
    >
    > void Member_Func2(A &a)
    > {
    > a.W *= 4;
    > a.X *= 4;
    >
    > // a.Y += 4; // Error can't access private
    > // a.Z += 6; // Error can't access private
    >
    > printf("W: %d\nX: %d\n", a.W, a.X);
    >
    > }
    >
    > int main(void)
    > {
    > A a;
    >
    > Non_Member_Func( a );
    >
    > a.Set_Func_Ptr( Member_Func );
    > a.Run();
    >
    > a.Set_Func_Ptr( Member_Func2) ;
    > a.Run();
    >
    > return 0;
    >
    > }

    I don't know if I understand your purpose to design such a class. It's
    weird to allow client to write a non-member function to access private
    member of a general purpose interface class. If you design a class for
    general purpose, you may only make interface ( or public member )
    exposed to client users rather than implementation ( private member).
    If the user can write non-member to directly access private member,
    why C++ need access control? except you use some trickery by access
    its memory directly.
     
    HL, Jul 6, 2008
    #2
    1. Advertising

  3. On 2008-07-06 01:38, Immortal Nephi wrote:
    > I design a class for general purpose. I do not allow a client to read
    > or modify interface and implemention. I allow them to write a new non-
    > member function outside of class' interface and implmention. The
    > problem is that non-member function cannot access private data member.
    >
    > The friend keyword is not the solution. I am aware that friend
    > keyword allows the non-member function to access private data member.
    >
    > If you define more than two non-member functions, you will want one of
    > some non-member function to be pointed to the member function pointer
    > at run-time. The client can decide to remove first non-member
    > function from the member function pointer and add another non-member
    > function at run-time. The member function pointer array is not
    > necessary according to my design.
    >
    > Does it mean that it is the only solution to access public data member
    > only?


    I'm not at all sure what you are trying to accomplish. If you want the
    user to be able to add functionality to your class without changing it
    you should declare the relevant member protected and allow the user to
    derived from it.

    --
    Erik Wikström
     
    Erik Wikström, Jul 6, 2008
    #3
    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. glen stark
    Replies:
    2
    Views:
    711
    Ron Natalie
    Oct 10, 2003
  2. Franz
    Replies:
    4
    Views:
    426
    Bob Hairgrove
    Oct 20, 2003
  3. Fraser Ross
    Replies:
    4
    Views:
    1,058
    Fraser Ross
    Aug 14, 2004
  4. shuisheng
    Replies:
    4
    Views:
    369
    peter koch
    Sep 26, 2006
  5. Peter
    Replies:
    2
    Views:
    278
    Öö Tiib
    Jun 6, 2013
Loading...

Share This Page