You are here:



We can overload assignment operator as a normal function.But we can not overload assignment operator as friend function why?  

Ummm, to me the term 'normal function' tends more towards meaning a non-member function rather than an instance (i.e. non-static) member function. Be careful with such terms. Normal for you is obviously not the same as normal for me.

The short answer is "because the ISO C++ standard states that it is so". It does this in section 13.5.3. There are similar constraints on operator() (function call), operator[] (subscripting), and operator-> (class member access) (section 13.5.4 through to section 13.5.6)

The most explicitly stated reason I could find (see quote below) is that operator=, along with operator[], operator(), and operator->, have to be non-static member functions is to ensure that their first operand (the object the function is called in the context of) is an lvalue.

In simple terms lvalues are things that can appear on the left hand side of an assignment operator. I recently provided more information on lvalues in response to another AllExperts question - see:

to read more on lvalues.

I found this reason given in "The C++ Programming Language", 3rd or special edition, Dr. Bjarne Stroustrup, the creator of C++, writes in section "11.2.2 Predefined Meanings for Operators":

   "..., operator=, operator[], operator(), and operator-> must be nonstatic
    member functions; this ensures that their first operands will be lvalues"

There is then a reference to section "4.9.6 Objects and Lvalues" of the same book.

In reality with modern, standard, C++ I suspect that even if the assignment operator were a non-member function an lvalue would be required for the first parameter for any rational, reasonable and usable signature for such a function.

This is because the object on the left hand side of an assignment would be modified by the operation - you are assigning new state to it after all, that is the meaning of the operation (at least in a reasonable implementation <g>). In order to modify the left hand side operand that parameter must be passed by-reference - for C++ this means as a pointer or a C++ reference - in a way that allows the value to be modified. In C++ passing by reference for modification means passing by pointer or reference to a non-const object. To work with operator expression syntax we have to use C++ references, not pointers. Thus such a non-member assignment operator would have a signature something like:

   T & operator=( T & lhs, T const & rhs );
Where lhs is the left hand side operand parameter and rhs is the right hand side operand parameter of some type T:

   lhs = rhs;
Note that the right hand side operand is passed by reference to a constant object - i.e. it cannot be modified - which makes sense for almost all cases.

Now it is too easy with non-const reference parameters to pass an rvalue (in simple terms: something that can appear on the right side of an assignment) that is unnamed and temporary, as mentioned in my lValue-required answer. As such, any modifications to such a parameter in a function will not be available to the caller, and this in the light of the likes of rvalues created from silent type conversions was deemed to be a potential cause of too many puzzling errors. So passing an rvalue as a non-const reference parameter is banned. As this usage is banned it means that a non-member assignment operator would be feasible for reasonable assignment operator definitions as the left hand side operand parameter, passed as a non-const reference, must be an lvalue..

Note this says nothing for potential strange, exotic, unexpected and confusing uses of operator= that non-member operator= functions could allow. We should of course avoid such unusual behaviours as it would cause much confusion to readers and users of such code. In general when overloading operators try to do as the integer types do.

Of course as the language requires assignment operators to have an lvalue on the left hand side any such exotic operator= function that did not ensure this may well violate the language rules - however finding a simple statement to this effect is I suspect not going to be easy.

Hence it seems sensible to force the issue by stating that they must be non-static member functions.

Hope this helps.


All Answers

Answers by Expert:

Ask Experts


Ralph McArdell


I am a software developer with more than 15 years C++ experience and over 25 years experience developing a wide variety of applications for Windows NT/2000/XP, UNIX, Linux and other platforms. I can help with basic to advanced C++, C (although I do not write just-C much if at all these days so maybe ask in the C section about purely C matters), software development and many platform specific and system development problems.


My career started in the mid 1980s working as a batch process operator for the now defunct Inner London Education Authority, working on Prime mini computers. I then moved into the role of Programmer / Analyst, also on the Primes, then into technical support and finally into the micro computing section, using a variety of 16 and 8 bit machines. Following the demise of the ILEA I worked for a small company, now gone, called Hodos. I worked on a part task train simulator using C and the Intel DVI (Digital Video Interactive) - the hardware based predecessor to Indeo. Other projects included a CGI based train simulator (different goals to the first), and various other projects in C and Visual Basic (er, version 1 that is). When Hodos went into receivership I went freelance and finally managed to start working in C++. I initially had contracts working on train simulators (surprise) and multimedia - I worked on many of the Dorling Kindersley CD-ROM titles and wrote the screensaver games for the Wallace and Gromit Cracking Animator CD. My more recent contracts have been more traditionally IT based, working predominately in C++ on MS Windows NT, 2000. XP, Linux and UN*X. These projects have had wide ranging additional skill sets including system analysis and design, databases and SQL in various guises, C#, client server and remoting, cross porting applications between platforms and various client development processes. I have an interest in the development of the C++ core language and libraries and try to keep up with at least some of the papers on the ISO C++ Standard Committee site at


©2016 All rights reserved.