member functions vs. non-member functions
-
Hi, all, What's your opinions on Scott Meyers' article: How Non-Member Functions Improve Encapsulation In that article, he gave the following algorithm:
if (f needs to be virtual) { make f a member function of C; } else if (f is operator>> or operator<< ) { make f a non-member function; if (f needs access to non-public members of C) { make f a friend of C; } } else if (f needs type conversions on its left-most argument) { make f a non-member function; if (f needs access to non-public members of C) { make f a friend of C; } else if (f can be implemented via C's public interface) { make f a non-member function; } else { make f a member function of C; }Do you agree with this algorithm? Regards, Lirong -
Hi, all, What's your opinions on Scott Meyers' article: How Non-Member Functions Improve Encapsulation In that article, he gave the following algorithm:
if (f needs to be virtual) { make f a member function of C; } else if (f is operator>> or operator<< ) { make f a non-member function; if (f needs access to non-public members of C) { make f a friend of C; } } else if (f needs type conversions on its left-most argument) { make f a non-member function; if (f needs access to non-public members of C) { make f a friend of C; } else if (f can be implemented via C's public interface) { make f a non-member function; } else { make f a member function of C; }Do you agree with this algorithm? Regards, LirongNot in the real world. Regards, Larry Antram Stardust Software "Those who choose to sacrifice freedom in order to gain security shall not have, nor do they deserve, either one" -- Benjamin Franklin
-
Not in the real world. Regards, Larry Antram Stardust Software "Those who choose to sacrifice freedom in order to gain security shall not have, nor do they deserve, either one" -- Benjamin Franklin
>Not in the real world. Why? In his articles, Scott gave reasons for his argument --- non-member functions can improve encapsulation. If the reasons are valid, why it is not practical in the real world? If those reasons are not valid, why they are not? Regards, Lirong
-
>Not in the real world. Why? In his articles, Scott gave reasons for his argument --- non-member functions can improve encapsulation. If the reasons are valid, why it is not practical in the real world? If those reasons are not valid, why they are not? Regards, Lirong
Sorry, I was being sarcastic. ;) I don't necissarily disagree with the non-member argument but more the generic algorithm... in particular the importance of "friend" classes in it (which, IMO, have a similar status as "goto"). Regards, Larry Antram Stardust Software "Those who choose to sacrifice freedom in order to gain security shall not have, nor do they deserve, either one" -- Benjamin Franklin
-
Sorry, I was being sarcastic. ;) I don't necissarily disagree with the non-member argument but more the generic algorithm... in particular the importance of "friend" classes in it (which, IMO, have a similar status as "goto"). Regards, Larry Antram Stardust Software "Those who choose to sacrifice freedom in order to gain security shall not have, nor do they deserve, either one" -- Benjamin Franklin
Larry Antram wrote: in particular the importance of "friend" classes in it (which, IMO, have a similar status as "goto"). I can express this as:
if (f needs access to non-public members of C)
{
Application.design.fix();
};) --Mike-- Just released - RightClick-Encrypt v1.3 - Adds fast & easy file encryption to Explorer My really out-of-date homepage Sonork-100.19012 Acid_Helm
-
Hi, all, What's your opinions on Scott Meyers' article: How Non-Member Functions Improve Encapsulation In that article, he gave the following algorithm:
if (f needs to be virtual) { make f a member function of C; } else if (f is operator>> or operator<< ) { make f a non-member function; if (f needs access to non-public members of C) { make f a friend of C; } } else if (f needs type conversions on its left-most argument) { make f a non-member function; if (f needs access to non-public members of C) { make f a friend of C; } else if (f can be implemented via C's public interface) { make f a non-member function; } else { make f a member function of C; }Do you agree with this algorithm? Regards, LirongDon't know about the algorithm, but I find the article very, VERY interesting. Now I view encapsulation in a quite another light :) I vote pro drink :beer:
-
Hi, all, What's your opinions on Scott Meyers' article: How Non-Member Functions Improve Encapsulation In that article, he gave the following algorithm:
if (f needs to be virtual) { make f a member function of C; } else if (f is operator>> or operator<< ) { make f a non-member function; if (f needs access to non-public members of C) { make f a friend of C; } } else if (f needs type conversions on its left-most argument) { make f a non-member function; if (f needs access to non-public members of C) { make f a friend of C; } else if (f can be implemented via C's public interface) { make f a non-member function; } else { make f a member function of C; }Do you agree with this algorithm? Regards, LirongHe is sooooo right. Actually, on stupid small classes I don't do it, but in every other class I do it and people yell at me that I’m not doing OOP. Now I have a nice argument… Concussus surgo. When struck I rise.
-
Larry Antram wrote: in particular the importance of "friend" classes in it (which, IMO, have a similar status as "goto"). I can express this as:
if (f needs access to non-public members of C)
{
Application.design.fix();
};) --Mike-- Just released - RightClick-Encrypt v1.3 - Adds fast & easy file encryption to Explorer My really out-of-date homepage Sonork-100.19012 Acid_Helm
Michael Dunn wrote: I can express this as: Sometimes yes, sometimes no... Personally I'd like proper ACL's in access specifiers... Len Holgate www.jetbyte.com The right code, right now.