3

Following is the abstraction of string class.

class string {
public:
    string(int n = 0) : buf(new char[n + 1]) { buf[0] = '\0'; }
    string(const char *);
    string(const string &);
    ~string() { delete [] buf; }

    char *getBuf() const;
    void setBuf(const char *);
    string & operator=(const string &);
    string operator+(const string &);
    string operator+(const char *);

    private:
       char *buf;
    };

    string operator+(const char *, const string &);
    std::ostream& operator<<(std::ostream&, const string&);

I want to know why these two operator overloaded functions

  string operator+(const char *, const string &);
  std::ostream& operator<<(std::ostream&, const string&);

are not class member function or friend functions? I know the two parameter operator overloaded functions are generally friend functions (I am not sure, I would appreciate if you could enlighten on this too) however my prof did not declare them as friend too. Following are the definitions of these function.

 string operator+(const char* s, const string& rhs) {

           string temp(s);
           temp = temp + rhs;
           return temp;
 }

 std::ostream& operator<<(std::ostream& out, const string& s) {
     return out << s.getBuf();
 }

Could anyone explain this with a small example, or direct me to similar question. Thanks in Advance. Regards

Improve this question
4
  • Do you know what friend functions offer over non-friend functions? Commented Jan 24, 2013 at 3:17
  • Friend functions are the ones who are not member function but can access private and protected members of class. Ok! I get it why above functions are not friend, they are not accessing buf! However, Why not member functions then? Commented Jan 24, 2013 at 3:20
  • Well, some will argue that in nearly all possible cases, functions should be non-member, non-friends, so as to increase encapsulation. However, in your example, those can't be member functions. Each of those operators takes two arguments. Notice how the ones in the class take only one. That is because the left side is already specified invisibly in the parameter list. It's the this pointer that all member functions receive. That means that in order to call a member function operator, the left side must be an instance of your class. Commented Jan 24, 2013 at 3:34
  • Thought about s + "Hi" and "Hi" + s? Commented Jan 24, 2013 at 3:38

4 Answers 4

Reset to default
2

The friend keyword grants access to the protected and private members of a class. It is not used in your example because those functions don't need to use the internals of string; the public interface is sufficient.

friend functions are never members of a class, even when defined inside class {} scope. This is a rather confusing. Sometimes friend is used as a trick to define a non-member function inside the class {} braces. But in your example, there is nothing special going on, just two functions. And the functions happen to be operator overloads.

It is poor style to define some operator+ overloads as members, and one as a non-member. The interface would be improved by making all of them non-members. Different type conversion rules are applied to a left-hand-side argument that becomes this inside the overload function, which can cause confusing bugs. So commutative operators usually should be non-members (friend or not).

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

It was an exercise professor gave us to make us understand the same thing I assume! Thanks again
@user1772218 Don't forget to click the checkmark on your favorite answer.
2

Let's talk about operator +. Having it as a non member allows code such as the following

string s1 = "Hi";
string s2 = "There";
string s3;

s3 = s1 + s2;
s3 = s1 + "Hi";
s3 = "Hi" + s1;

The last assignment statement is not possible if operator+ is a member rather than a namespace scope function. But if it is a namespace scope function, the string literal "Hi" is converted into a temporary string object using the converting constructor "string(const char *);" and passed to operator+.

In your case, it was possible to manage without making this function a friend as you have accessors for the private member 'buf'. But usually, if such accessors are not provided for whatever reason, these namespace scope functions need to be declared as friends.

Let's now talk about operator <<.

This is the insertion operator defined for ostream objects. If they have to print objects of a user defined type, then the ostream class definition needs to be modified, which is not recommended.

Therefore, the operator is overloaded in the namespace scope.

In both the cases, there is a well known principle of Argument Dependent Lookup that is the core reason behind the lookup of these namespace scope functions, also called Koenig Lookup.

Another interesting read is the Namespace Interface Principle

Improve this answer

Comments

1

Operators can be overloaded by member functions and by standalone (ordinary) functions. Whether the standalone overloading function is a friend or not is completely irrelevant. Friendship property has absolutely no relation to operator overloading.

When you use a standalone function, you might need direct access to "hidden" (private or protected) innards of the class, which is when you declare the function as friend. If you don't need this kind of privileged access (i.e. you can implement the required functionality in terms of public interface of the class), there's no need to declare the function as friend.

That's all there is to it.

Declaring a standalone overloading function as friend became so popular that people often call it "overloading by a friend function". This is really a misleading misnomer, since, as I said above, friendship per se has nothing to do with it.

Also, people sometimes declare overloading function as friend even if they don't need privileged access to the class. They do it because a friend function declaration can incorporate immediate inline definition of the function right inside the class definition. Without friend one'd be forced to do a separate declaration and a separate definition. A compact inline definition might just look "cleaner" in some cases.

Improve this answer

Comments

0

I'm a bit rusty with C++ overloads but I would complete the above answers by this simple memo :

  • If the type of the left-hand operand is a user-defined type (a class, for instance), you should (but you don't have to) implement the operator overloading as a member function. And keep in mind that if these overloads -- which will most likely be like +, +=, ++... -- modify the left-hand operand, they return a reference on the calling type (actually on the modified object). That is why, e.g. in Coplien's canonical form, the operator= overloading is a member function and returns a "UserClassType &" (because actually the function returns *this).

  • If the type of the left-hand operand is a system type (int, ostream, etc...), you should implement the operator overloading as a standalone function.

By the way, I've always been told that friend keyword is bad, ugly and eats children. I guess it's mainly a matter of coding style, but I would therefore advice you to be careful when you use it, and avoid it when you can. (I've never been faced to a situation where its use was mandatory yet, so I can't really tell ! )

(And sorry for my bad English I'm a bit rusty with it too)

Scy

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.