You are here:

C++/operator overloading


hello sir

thanks for giving answer but there are a lot of points which r not yet clear to me . can i come to know which operator take a name not  a value?
2. what is the difference between evaluation of a code at compile time or at run time? and how can i come to know again which expressions evaluated at runtime or which one at compile time?

pls explain to make it more clear for me

thank you

Followup To

Question -

hello sir

why just four operators cant be overloaded in c++
is there any special reason behind it for not being overloded .explain this
thank you

Answer -
In fact the list is as follows:


The reasons are ones of practicality and sanity!

The reason for the first three is that they take a name not a value as their second operand which as far as I can make out would only have meaning during compilation and not runtime - the compiled code generally has lost the names of namespaces, types and members and if they are not externally visible also the names of functions and variables. Stroustrup states that these are also the primary means of referring to members and uses the term "lead to subtleties" if they were allowed to be overloaded. He refers to his book "Design and evolution of C++" for more detail - which I have not got around to reading yet, but is on my list of books to read one day!

The ternary operator ?: requires three operands, one of which is an expression. How do you pass an expression to a function? (You cannot, functions only accept values as arguments).

sizeof, like . etc. is best not messed with it does what it does, why would you need to overload it other than to give erroneous results? Further sizeof is generally evaluated at compile time and in many cases does not even bother to evaluate the expression it is passed. This is because it is the compiler you are asking of the size of the object or type in question as only it knows what the size is. The size is not known at runtime. Which brings is to the fact that sizeof works with both objects and types; how do you pass a type to a function? (You cannot).

Likewise, typeid takes a type as its operand.

So, to sum up the reasons are that they require compile-time only information and/or would cause problems elsewhere if they were allowed to be overloaded.  

Well, as there are only 6 operators listed that you cannot overload it seems not to difficult a task to remember them.

Also you will find that you probably do not want to overload these operators anyway so I doubt it will be much of an issue.

Oh, and if you do try to implement non-supported operator overloads the compiler should give you some errors, which should be enough to remind you.

1/ Err, because you know what the operator does. If you do not understand the use of an operator why would you even be considering overloading it? Example:
You know that :: is used to qualify names: e.g. namespacename::classname::membername makes sense but using it with values makes no sense:  1::2::3 and "string"::"anotherstring" are not good C++. If you do not see that this is so then I suggest you learn more basic C++ before worrying too much about such corners of the language.

2/ If something is evaluated at compile time the compiler does the work of evaluation. If it is done at run time then the code generated by the compiler does the evaluation when you run the program.

Sorry I missed your final question, here is that piece:

You cannot always know where an expression is evaluated. However understanding what the compiler does is a great help. In some cases it follows from the description in standard when evaluation occurs, even if this is not explicitly obvious <g>.

For example the standard’s section on sizeof states that it returns a constant and that one form can accept a type and the other form accepts an expression that is not evaluated. All these point to the evaluation being done by the compiler. If sizeof is passed an expression the expression is not evaluated because all sizeof is really interested in is the type of the expression. Types are really only a compiler thing, other than at the most basic level of integer type (signed/unsigned) / floating point type as they are handled differently by processors. The clinching argument for sizeof is that it returns a constant – which implies it can be used anywhere a constant expression is used (except in pre-processor directives, as sizeof is evaluated during compilation proper which happens after pre-processing). For example you can define an array to have enough elements for the size of a specific type:

int x(0x12345678);
char x_bytes[sizeof(x)];
for ( int index(0); index < sizeof(x); ++index)
   x_bytes[index] = x & 0xff;
   x >>= 8;

Now built in arrays like x_bytes above have their memory allocated by the compiler, so the compiler must know the number of elements in the array, so the array size value(s) have to be constant, i.e. they must be known at compile time. So, as we can use values returned by sizeof to specify the number of elements in an array these values must also be known at compile time...

So a good hint that something is either known at compile time (i.e. evaluated by the compiler) or must be known at compile time is that a constant or constant expression is involved and/or types are involved.

However consider the following:

int main()
   int a(2);
   int b(2);
   int c(a+b);
   std::cout << c << '\n';

Now strictly speaking this piece of code involves three variables: a, b and c. If you build this program with no optimisations then that is what you will get. However if you turn on optimisations then you will most likely find that the compiler has been clever and reduced this code to:

int main()
   std::cout << 4 << '\n';

Or rather the machine code equivalent. It can do this because the two forms have the same result. a, b, and c are not used anywhere else so removing them and replacing the end result of the sequence with just the result has the same effect, other than memory layout and timing.

In these cases the compiler has obviously done some evaluation that should be done at runtime for us during compilation to make the code smaller and probably faster.

However I would still consider all the operations as runtime as the compiler may or may not optimise the code for us, and any optimisations it does for us have to leave the resultant code having the same observable results.  


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


©2017 All rights reserved.