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!

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

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

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.

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.

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?

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;
}

---

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.

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.