Friend function

This is a discussion on Friend function within the C++ Programming forums, part of the General Programming Boards category; I'm having a bit of trouble with friend functions and classes... I know that you can have a class be ...

  1. #1
    Registered User
    Join Date
    May 2004
    Posts
    73

    Friend function

    I'm having a bit of trouble with friend functions and classes...

    I know that you can have a class be freely accessed by a certain function if you use the friend operator...

    Code:
    class MyClassType;
    int A( MyClassType* MyClass );
    
    class MyClassType
    {
       friend int A( MyClassType* MyClass );
    
    private:
       int B;
    };
    
    int A( MyClassType* MyClass )
    {
       MyClass->B = 3;
    }
    IIRC, this lets A() access anything it wants in the MyClassType. What do I do if I only want A() to be able to call one function in a certain class?

    Code:
    class GCoreType;
    bool HandleEvent( GCoreType* Core, EventType* Event );
    
    class GCoreType
    {
    private:
       ... // Data and stuff
       bool ReceiveCommandFromHandleEvent( int Command ) friend bool HandleEvent( GCoreType* Core, EventType* Event );
    
    public:
       ... // Other stuff
    };
    
    bool HandleEvent( GCoreType* Core, EventType* Event )
    {
       if( Event->eType == appStopEvent )
       {
          Core->ReceiveCommandFromHandleEvent( 0 );
       }
    
       return true;
    }
    What I'm trying to do is instead of making the entire GCoreType class accessible to the HandleEvent function, i just want ONE function on the GCoreType to be accessible (along with all the public junk of course).

    I know that up there is syntactically incorrect. What I want to know is if what I'm trying to do is possible.

    Thanks!

  2. #2
    Toaster Zach L.'s Avatar
    Join Date
    Aug 2001
    Posts
    2,686
    Well, there is no easy way to go about this that I know of (there is one I can think of, but it is truly an abuse of language features).

    But, there really shouldn't be any need to do this. Granting a friend access to the private data is not as bad as it seems, because you, the implementer of the class, are the one implementing the function, so you aren't exposing anything that shouldn't be exposed, and you can "implement the function responsibly" (yes, I know that sounds like a horrible phrase).

    Cheers
    The word rap as it applies to music is the result of a peculiar phonological rule which has stripped the word of its initial voiceless velar stop.

  3. #3
    aoeuhtns
    Join Date
    Jul 2005
    Posts
    581
    I think there might be an absurd and painful way to do this via derived classes. However, that is only a supposition; it's up to you to find out if this turns out to be true (and I'm betting it isn't) and you shouldn't do this anyway. Using friends does not break encapsulation, as Zach L. said.

    (Well, if you ask me, declaring everything public does not break encapsulation either. It's morons who don't follow the documented interface who break encapsulation. And they get what they deserve. But that's just me.)

  4. #4
    Registered User
    Join Date
    Jun 2005
    Posts
    6,664
    Quote Originally Posted by Rashakil Fol
    (Well, if you ask me, declaring everything public does not break encapsulation either. It's morons who don't follow the documented interface who break encapsulation. And they get what they deserve. But that's just me.)
    Yes, it's just you. The notion of encapsulation involves controlling design of code so that access to the documented interface is allowed, and arbitrary access any undocumented interface (i.e. the implementation details) is prevented.

    Making things private or public (or protected) achieves that in C++, by ensuring the compiler will choke when a "moron" attempts to access undocumented features of a class.

  5. #5
    aoeuhtns
    Join Date
    Jul 2005
    Posts
    581
    The notion of encapsulation is simply putting things behind an interface so that other programmers don't have to worry about the details of the implementation. When you're writing C, if you're using library X but you think that you might need to use library Y in other situations (like other platforms), you would put calls to library X behind a cloud of functions. That's encapsulation.

    Private and protected are just extra features of C++, useful for programming as if your objects are under a state of siege; encapsulation regularly happens in other languages without this protectionism.

    If having unnecessarily public members breaks encapsulation, then leaving your door unlocked makes you a burglar.

  6. #6
    Registered User
    Join Date
    Jan 2005
    Posts
    7,344
    No, leaving your door unlocked "breaks" protection of your house, making it easier for a "moron" to burgle you. Leaving implementation details public breaks protection of your class, making it easier for a moron to misuse it.

    The language feature is there, why would you not use it?

  7. #7
    Magically delicious LuckY's Avatar
    Join Date
    Oct 2001
    Posts
    856
    You could simply make HandleEvent a static member function of GCoreType.
    Code:
    class GCoreType
    {
    private:
       ... // Data and stuff
       bool ReceiveCommandFromHandleEvent( int Command );
       static bool HandleEvent( GCoreType* Core, EventType* Event );
    
    public:
       ... // Other stuff
    };
    
    bool GCoreType::HandleEvent( GCoreType* Core, EventType* Event )
    {
       if( Event->eType == appStopEvent )
       {
          Core->ReceiveCommandFromHandleEvent( 0 );
       }
    
       return true;
    }

  8. #8
    aoeuhtns
    Join Date
    Jul 2005
    Posts
    581
    Quote Originally Posted by Daved
    No, leaving your door unlocked "breaks" protection of your house, making it easier for a "moron" to burgle you. Leaving implementation details public breaks protection of your class, making it easier for a moron to misuse it.

    The language feature is there, why would you not use it?
    I do use it. But it's not encapsulation; it's self-documenting code, with enforcement of the documentation. Encapsulation isn't the protection.

  9. #9
    Registered User
    Join Date
    Jan 2005
    Posts
    7,344
    Ok, so you were just making a semantic point about terms. Making members private prevents the breaking of encapsulation even if it doesn't break it directly. I don't know if I agree completely with that, but it doesn't matter since the benefits of using the private access specifiers are clearly the same no matter what you call it.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 4
    Last Post: 05-13-2011, 09:28 AM
  2. Compiling sample DarkGDK Program
    By Phyxashun in forum Game Programming
    Replies: 6
    Last Post: 01-27-2009, 03:07 AM
  3. We Got _DEBUG Errors
    By Tonto in forum Windows Programming
    Replies: 5
    Last Post: 12-22-2006, 05:45 PM
  4. Game Pointer Trouble?
    By Drahcir in forum C Programming
    Replies: 8
    Last Post: 02-04-2006, 02:53 AM
  5. Quack! It doesn't work! >.<
    By *Michelle* in forum C++ Programming
    Replies: 8
    Last Post: 03-02-2003, 12:26 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21