C/C++ C++ Friend Functions: Benefits & Tradeoffs

  • Thread starter Thread starter neurocomp2003
  • Start date Start date
  • Tags Tags
    C++ Functions
AI Thread Summary
Declaring functions as FRIEND in C++ allows access to a class's private and protected members, which can be useful for functions like Print, Save, and Load that need to interact closely with class internals. However, this approach is often viewed as a workaround rather than a best practice in object-oriented design. The discussion highlights that using FRIEND functions does not significantly impact memory or computational efficiency, as the overhead is minimal compared to the benefits of maintaining encapsulation through member functions. Organizing functions into namespaces or static classes is suggested as a way to improve code organization, but the necessity of FRIEND functions for accessing private members is debated. The conversation also touches on the redundancy of getter and setter methods, with a sentiment expressed against their frequent use. Overall, the focus is on finding a balance between clean design and practical functionality in code organization for a 3D engine and neural networks.
neurocomp2003
Messages
1,359
Reaction score
4
Sup,
is there a purpose to declaring functions as FRIEND rather than as member functions of a class...types of functions I'm looking towards: Print Save Load.

I'm trying to organize my code(3D engine/neural nets) and I'm looking to put those above 3 functions in a separate namespace or as friends but i don't know if it is wise.

Is there a memory trade off to using FRIEND rather than just declaring the function in the class as normally would.
Is there a computational trade off?

Are FRIENDs bad in general(not as apart of OO design)?

thx
Neurocomp
 
Technology news on Phys.org
Functions aren't objects. Sticking a couple of functions like print(), save(), and load() into a class is not object-oriented design. That's just procedural design stuffed into a class. But, I digress...

Friend classes and functions are sometimes necessary when a class or function needs to be able to access protected members in another class. Honestly, most of the time, declaring friends is a cop-out, or a way to avoid having to do a lot of redesign.

The memory and speed trade-offs are almost non-existent. True member functions occupy space in vtables, thus giving member function calls a slight overhead. Each class's vtable will also occupy a bit more memory, but it's really hardly relevant.

If the most time-consuming thing your code is doing is making function calls, you are one hell of a 3D and neural net programmer!

- Warren
 
I knew functions aren't objects I'm just wondering about the organizing over classes(which I thought was OO-selflearning sucks)
if I wanted to organize these functions in classes/namespaces
ie. collecting all the save/load/print/draw functions for objects in both my engines using their respective names as namespaces or classes of static functions -> Save::Save(NeuralNet);

eg. namespace SAVE {
Save(...1...)
Save(...2..)
}
OR
class SAVE{
static Save(...1...)
static Save(...1...)
};

and yeah i knew "friends" are usually copouts but inorder for me to access the protected and private members in either of theses organization schemes, i would either inline or use friends.

Would you suggest doing either of these or just leaving them as member functions in the original classes?

Oh yeah what's your opinion on sets/gets are they needed? I'm sick of writing them.

and do you know of any good STL tutorial sites? I'm too lazy to write my own DS though I have them lying around.


"If the most time-consuming thing your code is doing is making function calls, you are one hell of a 3D and neural net programmer!" yo quiero taco bell...its late and my brain isn't comprehending was that a complement or a sarcastic remark =]

either way thanks for the help
 
Last edited:
Thread 'Is this public key encryption?'
I've tried to intuit public key encryption but never quite managed. But this seems to wrap it up in a bow. This seems to be a very elegant way of transmitting a message publicly that only the sender and receiver can decipher. Is this how PKE works? No, it cant be. In the above case, the requester knows the target's "secret" key - because they have his ID, and therefore knows his birthdate.

Similar threads

Replies
23
Views
2K
Replies
1
Views
9K
Replies
9
Views
3K
Replies
89
Views
6K
Replies
7
Views
11K
Replies
2
Views
2K
Replies
10
Views
3K
Back
Top