Template Class Assignment Operator Errors

Operator overloading[edit]

Operator overloading (less commonly known as ad-hoc polymorphism) is a specific case of polymorphism (part of the OO nature of the language) in which some or all operators like , or are treated as polymorphic functions and as such have different behaviors depending on the types of its arguments. Operator overloading is usually only syntactic sugar. It can easily be emulated using function calls.

Consider this operation:

Using operator overloading permits a more concise way of writing it, like this:

a + b * c

(Assuming the operator has higher precedence than .)

Operator overloading can provide more than an aesthetic benefit, since the language allows operators to be invoked implicitly in some circumstances. Problems, and critics, to the use of operator overloading arise because it allows programmers to give operators completely free functionality, without an imposition of coherency that permits to consistently satisfy user/reader expectations. Usage of the operator is an example of this problem.

// The expressiona<<1;

Will return twice the value of if is an integer variable, but if is an output stream instead this will write "1" to it. Because operator overloading allows the programmer to change the usual semantics of an operator, it is usually considered good practice to use operator overloading with care.

To overload an operator is to provide it with a new meaning for user-defined types. This is done in the same fashion as defining a function. The basic syntax follows (where @ represents a valid operator):

return_typeoperator@(argument_list){// ... definition}

Not all operators may be overloaded, new operators cannot be created, and the precedence, associativity or arity of operators cannot be changed (for example ! cannot be overloaded as a binary operator). Most operators may be overloaded as either a member function or non-member function, some, however, must be defined as member functions. Operators should only be overloaded where their use would be natural and unambiguous, and they should perform as expected. For example, overloading + to add two complex numbers is a good use, whereas overloading * to push an object onto a vector would not be considered good style.

Operator overloading should only be utilized when the meaning of the overloaded operator's operation is unambiguous and practical for the underlying type and where it would offer a significant notational brevity over appropriately named function calls.

A simple Message Header
// sample of Operator Overloading#include<string>classPlMessageHeader{std::stringm_ThreadSender;std::stringm_ThreadReceiver;//return true if the messages are equal, false otherwiseinlinebooloperator==(constPlMessageHeader&b)const{return((b.m_ThreadSender==m_ThreadSender)&&(b.m_ThreadReceiver==m_ThreadReceiver));}//return true if the message is for nameinlineboolisFor(conststd::string&name)const{return(m_ThreadReceiver==name);}//return true if the message is for nameinlineboolisFor(constchar*name)const{return(m_ThreadReceiver==name);// since name type is std::string, it becomes unsafe if name == NULL}};

The use of the keyword in the example above is technically redundant, as functions defined within a class definition like this are implicitly inline.

Operators as member functions[edit]

Aside from the operators which must be members, operators may be overloaded as member or non-member functions. The choice of whether or not to overload as a member is up to the programmer. Operators are generally overloaded as members when they:

  1. change the left-hand operand, or
  2. require direct access to the non-public parts of an object.

When an operator is defined as a member, the number of explicit parameters is reduced by one, as the calling object is implicitly supplied as an operand. Thus, binary operators take one explicit parameter and unary operators none. In the case of binary operators, the left hand operand is the calling object, and no type coercion will be done upon it. This is in contrast to non-member operators, where the left hand operand may be coerced.

// binary operator as member function//Vector2D Vector2D::operator+(const Vector2D& right)const [...]// binary operator as non-member function//Vector2D operator+(const Vector2D& left, const Vector2D& right)[...]// binary operator as non-member function with 2 arguments //friend Vector2D operator+(const Vector2D& left, const Vector2D& right) [...]// unary operator as member function//Vector2D Vector2D::operator-()const {...}// unary operator as non-member function[...]//Vector2D operator-(const Vector2D& vec) [...]

Overloadable operators[edit]

Arithmetic operators[edit]
  • + (addition)
  • - (subtraction)
  • * (multiplication)
  • / (division)
  • % (modulus)

As binary operators, these involve two arguments which do not have to be the same type. These operators may be defined as member or non-member functions. An example illustrating overloading for the addition of a 2D mathematical vector type follows.


It is good style to only overload these operators to perform their customary arithmetic operation. Because operator has been overloaded as member function, it can access private fields.

Bitwise operators[edit]
  • ^ (XOR)
  • | (OR)
  • & (AND)
  • ~ (complement)
  • << (shift left, insertion to stream)
  • >> (shift right, extraction from stream)

All of the bitwise operators are binary, except complement, which is unary. It should be noted that these operators have a lower precedence than the arithmetic operators, so if ^ were to be overloaded for exponentiation, x ^ y + z may not work as intended. Of special mention are the shift operators, << and >>. These have been overloaded in the standard library for interaction with streams. When overloading these operators to work with streams the rules below should be followed:

  1. overload << and >> as friends (so that it can access the private variables with the stream be passed in by references
  2. (input/output modifies the stream, and copying is not allowed)
  3. the operator should return a reference to the stream it receives (to allow chaining, cout << 3 << 4 << 5)
An example using a 2D vector
friendostream&operator<<(ostream&out,constVector2D&vec)// output{out<<"("<<vec.x()<<", "<<vec.y()<<")";returnout;}friendistream&operator>>(istream&in,Vector2D&vec)// input{doublex,y;// skip opening paranthesisin.ignore(1);// read xin>>x;vec.set_x(x);// skip delimiterin.ignore(2);// read yin>>y;vec.set_y(y);// skip closing paranthesisin.ignore(1);returnin;}
Assignment operator[edit]

The assignment operator, =, must be a member function, and is given default behavior for user-defined classes by the compiler, performing an assignment of every member using its assignment operator. This behavior is generally acceptable for simple classes which only contain variables. However, where a class contains references or pointers to outside resources, the assignment operator should be overloaded (as general rule, whenever a destructor and copy constructor are needed so is the assignment operator), otherwise, for example, two strings would share the same buffer and changing one would change the other.

In this case, an assignment operator should perform two duties:

  1. clean up the old contents of the object
  2. copy the resources of the other object

For classes which contain raw pointers, before doing the assignment, the assignment operator should check for self-assignment, which generally will not work (as when the old contents of the object are erased, they cannot be copied to refill the object). Self assignment is generally a sign of a coding error, and thus for classes without raw pointers, this check is often omitted, as while the action is wasteful of cpu cycles, it has no other effect on the code.

classBuggyRawPointer{// example of super-common mistakeT*m_ptr;public:BuggyRawPointer(T*ptr):m_ptr(ptr){}BuggyRawPointer&operator=(BuggyRawPointerconst&rhs){deletem_ptr;// free resource; // Problem here!m_ptr=0;m_ptr=rhs.m_ptr;return*this;};};BuggyRawPointerx(newT);x=x;// We might expect this to keep x the same. This sets x.m_ptr == 0. Oops!// The above problem can be fixed like so:classWithRawPointer2{T*m_ptr;public:WithRawPointer2(T*ptr):m_ptr(ptr){}WithRawPointer2&operator=(WithRawPointer2const&rhs){if(this!=&rhs){deletem_ptr;// free resource;m_ptr=0;m_ptr=rhs.m_ptr;}return*this;};};WithRawPointer2x2(newT);x2=x2;// x2.m_ptr unchanged.

Another common use of overloading the assignment operator is to declare the overload in the private part of the class and not define it. Thus any code which attempts to do an assignment will fail on two accounts, first by referencing a private member function and second fail to link by not having a valid definition. This is done for classes where copying is to be prevented, and generally done with the addition of a privately declared copy constructor

classDoNotCopyOrAssign{public:DoNotCopyOrAssign(){};private:DoNotCopyOrAssign(DoNotCopyOrAssignconst&);DoNotCopyOrAssign&operator=(DoNotCopyOrAssignconst&);};classMyClass:publicDoNotCopyOrAssign{public:MyClass();};MyClassx,y;x=y;// Fails to compile due to private assignment operator;MyClassz(x);// Fails to compile due to private copy constructor.
Relational operators[edit]
  • == (equality)
  • != (inequality)
  • > (greater-than)
  • < (less-than)
  • >= (greater-than-or-equal-to)
  • <= (less-than-or-equal-to)

All relational operators are binary, and should return either true or false. Generally, all six operators can be based off a comparison function, or each other, although this is never done automatically (e.g. overloading > will not automatically overload < to give the opposite). There are, however, some templates defined in the header <utility>; if this header is included, then it suffices to just overload operator== and operator<, and the other operators will be provided by the STL.

Logical operators[edit]
  • ! (NOT)
  • && (AND)
  • || (OR)

The logical operators AND are used when evaluating two expressions to obtain a single relational result.The operator corresponds to the boolean logical operation AND,which yields true if operands are true,and false otherwise.The following panel shows the result of operator evaluating the expression.

The ! operator is unary, && and || are binary. It should be noted that in normal use, && and || have "short-circuit" behavior, where the right operand may not be evaluated, depending on the left operand. When overloaded, these operators get function call precedence, and this short circuit behavior is lost. It is best to leave these operators alone.


If the result of Function1() is false, then Function2() is not called.


Both Function3() and Function4() will be called no matter what the result of the call is to Function3() This is a waste of CPU processing, and worse, it could have surprising unintended consequences compared to the expected "short-circuit" behavior of the default operators. Consider:

externMyObject*ObjectPointer;boolFunction1(){returnObjectPointer!=null;}boolFunction2(){returnObjectPointer->MyMethod();}MyBoolFunction3(){returnObjectPointer!=null;}MyBoolFunction4(){returnObjectPointer->MyMethod();}booloperator&&(MyBoolconst&,MyBoolconst&);Function1()&&Function2();// Does not execute Function2() when pointer is nullFunction3()&&Function4();// Executes Function4() when pointer is null
Compound assignment operators[edit]
  • += (addition-assignment)
  • -= (subtraction-assignment)
  • *= (multiplication-assignment)
  • /= (division-assignment)
  • %= (modulus-assignment)
  • &= (AND-assignment)
  • |= (OR-assignment)
  • ^= (XOR-assignment)
  • <<= (shift-left-assignment)
  • >>= (shift-right-assignment)

Compound assignment operators should be overloaded as member functions, as they change the left-hand operand. Like all other operators (except basic assignment), compound assignment operators must be explicitly defined, they will not be automatically (e.g. overloading = and + will not automatically overload +=). A compound assignment operator should work as expected: A @= B should be equivalent to A = A @ B. An example of += for a two-dimensional mathematical vector type follows.

Increment and decrement operators[edit]
  • ++ (increment)
  • -- (decrement)

Increment and decrement have two forms, prefix (++i) and postfix (i++). To differentiate, the postfix version takes a dummy integer. Increment and decrement operators are most often member functions, as they generally need access to the private member data in the class. The prefix version in general should return a reference to the changed object. The postfix version should just return a copy of the original value. In a perfect world, A += 1, A = A + 1, A++, ++A should all leave A with the same value.

SomeValue&SomeValue::operator++()// prefix{++data;return*this;}SomeValueSomeValue::operator++(intunused)// postfix{SomeValueresult=*this;++data;returnresult;}

Often one operator is defined in terms of the other for ease in maintenance, especially if the function call is complex.

SomeValueSomeValue::operator++(intunused)// postfix{SomeValueresult=*this;++(*this);// call SomeValue::operator++()returnresult;}
Subscript operator[edit]

The subscript operator, [ ], is a binary operator which must be a member function (hence it takes only one explicit parameter, the index). The subscript operator is not limited to taking an integral index. For instance, the index for the subscript operator for the std::map template is the same as the type of the key, so it may be a string etc. The subscript operator is generally overloaded twice; as a non-constant function (for when elements are altered), and as a constant function (for when elements are only accessed).

Function call operator[edit]

The function call operator, ( ), is generally overloaded to create objects which behave like functions, or for classes that have a primary operation. The function call operator must be a member function, but has no other restrictions - it may be overloaded with any number of parameters of any type, and may return any type. A class may also have several definitions for the function call operator.

Address of, Reference, and Pointer operators[edit]

These three operators, operator&(), operator*() and operator->() can be overloaded. In general these operators are only overloaded for smart pointers, or classes which attempt to mimic the behavior of a raw pointer. The pointer operator, operator->() has the additional requirement that the result of the call to that operator, must return a pointer, or a class with an overloaded operator->(). In general A == *&A should be true.

Note that overloading operator& invokes undefined behavior:

ISO/IEC 14882:2003, Section 5.3.1
The address of an object of incomplete type can be taken, but if the complete type of that object is a class type that declares operator&() as a member function, then the behavior is undefined (and no diagnostic is required).
classT{public:constmemberFunction()const;};// forward declarationclassDullSmartReference;classDullSmartPointer{private:T*m_ptr;public:DullSmartPointer(T*rhs):m_ptr(rhs){};DullSmartReferenceoperator*()const{returnDullSmartReference(*m_ptr);}T*operator->()const{returnm_ptr;}};classDullSmartReference{private:T*m_ptr;public:DullSmartReference(T&rhs):m_ptr(&rhs){}DullSmartPointeroperator&()const{returnDullSmartPointer(m_ptr);}// conversion operatoroperatorT(){return*m_ptr;}};DullSmartPointerdsp(newT);dsp->memberFunction();// calls T::memberFunctionTt;DullSmartReferencedsr(t);dsp=&dsr;t=dsr;// calls the conversion operator

These are extremely simplified examples designed to show how the operators can be overloaded and not the full details of a SmartPointer or SmartReference class. In general you won't want to overload all three of these operators in the same class.

Comma operator[edit]

The comma operator,() , can be overloaded. The language comma operator has left to right precedence, the operator,() has function call precedence, so be aware that overloading the comma operator has many pitfalls.


For non overloaded comma operator, the order of execution will be Function1(), Function2(); With the overloaded comma operator, the compiler can call either Function1(), or Function2() first.

Member Reference operators[edit]

The two member access operators, operator->() and operator->*() can be overloaded. The most common use of overloading these operators is with defining expression template classes, which is not a common programming technique. Clearly by overloading these operators you can create some very unmaintainable code so overload these operators only with great care.

When the -> operator is applied to a pointer value of type (T *), the language dereferences the pointer and applies the . member access operator (so x->m is equivalent to (*x).m). However, when the -> operator is applied to a class instance, it is called as a unary postfix operator; it is expected to return a value to which the -> operator can again be applied. Typically, this will be a value of type (T *), as in the example under Address of, Reference, and Pointer operators above, but can also be a class instance with operator->() defined; the language will call operator->() as many times as necessary until it arrives at a value of type (T *).

Memory management operators[edit]
  • new (allocate memory for object)
  • new[ ] (allocate memory for array)
  • delete (deallocate memory for object)
  • delete[ ] (deallocate memory for array)

The memory management operators can be overloaded to customize allocation and deallocation (e.g. to insert pertinent memory headers). They should behave as expected, new should return a pointer to a newly allocated object on the heap, delete should deallocate memory, ignoring a NULL argument. To overload new, several rules must be followed:

  • new must be a member function
  • the return type must be void*
  • the first explicit parameter must be a size_t value

To overload delete there are also conditions:

  • delete must be a member function (and cannot be virtual)
  • the return type must be void
  • there are only two forms available for the parameter list, and only one of the forms may appear in a class:
Conversion operators[edit]

Conversion operators enable objects of a class to be either implicitly (coercion) or explicitly (casting) converted to another type. Conversion operators must be member functions, and should not change the object which is being converted, so should be flagged as constant functions. The basic syntax of a conversion operator declaration, and declaration for an int-conversion operator follows.

operator''type''()const;// const is not necessary, but is good styleoperatorint()const;

Notice that the function is declared without a return-type, which can easily be inferred from the type of conversion. Including the return type in the function header for a conversion operator is a syntax error.

doubleoperatordouble()const;// error - return type included

Operators which cannot be overloaded[edit]

  • ?: (conditional)
  • . (member selection)
  • .* (member selection with pointer-to-member)
  • :: (scope resolution)
  • (object size information)
  • typeid (object type information)

To understand the reasons why the language doesn't permit these operators to be overloaded, read "Why can't I overload dot, ::, , etc.?" at the Bjarne Stroustrup's C++ Style and Technique FAQ ( http://www.stroustrup.com/bs_faq2.html#overload-dot ).

There are many pitfalls that a C++ developer may encounter. This can make quality programming very hard and maintenance very expensive. Learning the language syntax and having good programming skills in similar languages, like C# and Java, just isn’t enough to utilize C++’s full potential. It requires years of experience and great discipline to avoid errors in C++. In this article, we are going to take a look at some of the common mistakes that are made by developers of all levels if they are not careful enough with C++ development.

Common Mistake #1: Using “new” and ”delete” Pairs Incorrectly

No matter how much we try, it is very difficult to free all dynamically allocated memory. Even if we can do that, it is often not safe from exceptions. Let us look at a simple example:

If an exception is thrown, the “a” object is never deleted. The following example shows a safer and shorter way to do that. It uses auto_ptr which is deprecated in C++11, but the old standard is still widely used. It can be replaced with C++11 unique_ptr or scoped_ptr from Boost if possible.

No matter what happens, after creating the “a” object it will be deleted as soon as the program execution exits from the scope.

However, this was just the simplest example of this C++ problem. There are many examples when deleting should be done at some other place, perhaps in an outer function or another thread. That is why the use of new/delete in pairs should be completely avoided and appropriate smart pointers should be used instead.

Common Mistake #2: Forgotten Virtual Destructor

This is one of the most common errors that leads to memory leaks inside derived classes if there is dynamic memory allocated inside them. There are some cases when virtual destructor is not desirable, i.e. when a class is not intended for inheritance and its size and performance is crucial. Virtual destructor or any other virtual function introduces additional data inside a class structure, i.e. a pointer to a virtual table which makes the size of any instance of the class bigger.

However, in most cases classes can be inherited even if it is not originally intended. So it is a very good practice to add a virtual destructor when a class is declared. Otherwise, if a class must not contain virtual functions due to performance reasons, it is a good practice to put a comment inside a class declaration file indicating that the class should not be inherited. One of the best options to avoid this issue is to use an IDE that supports virtual destructor creation during a class creation.

One additional point to the subject are classes/templates from the standard library. They are not intended for inheritance and they do not have a virtual destructor. If, for example, we create a new enhanced string class that publicly inherits from std::string there is possibility that somebody will use it incorrectly with a pointer or a reference to std::string and cause a memory leak.

To avoid such C++ issues, a safer way of reusing of a class/template from the standard library is to use private inheritance or composition.

Common Mistake #3: Deleting an Array With “delete” or Using a Smart Pointer

Creating temporary arrays of dynamic size is often necessary. After they are not required anymore, it is important to free the allocated memory. The big problem here is that C++ requires special delete operator with [] brackets, which is forgotten very easily. The delete[] operator will not just delete the memory allocated for an array, but it will first call destructors of all objects from an array. It is also incorrect to use the delete operator without [] brackets for primitive types, even though there is no destructor for these types. There is no guarantee for every compiler that a pointer to an array will point to the first element of the array, so using delete without [] brackets can result in undefined behaviour too.

Using smart pointers, such as auto_ptr, unique_ptr<T>, shared_ptr, with arrays is also incorrect. When such a smart pointer exits from a scope, it will call a delete operator without [] brackets which results in the same issues described above. If using of a smart pointer is required for an array, it is possible to use scoped_array or shared_array from Boost or a unique_ptr<T[]> specialization.

If functionality of reference counting is not required, which is mostly the case for arrays, the most elegant way is to use STL vectors instead. They don’t just take care of releasing memory, but offer additional functionalities as well.

Common Mistake #4: Returning a Local Object by Reference

This is mostly a beginner’s mistake, but it is worth mentioning since there is a lot of legacy code that suffers from this issue. Let’s look at the following code where a programmer wanted to do some kind of optimization by avoiding unnecessary copying:

The object “sum” will now point to the local object “result”. But where is the object “result” located after the SumComplex function is executed? Nowhere. It was located on the stack, but after the function returned the stack was unwrapped and all local objects from the function were destructed. This will eventually result in an undefined behaviour, even for primitive types. To avoid performance issues, sometimes it is possible to use return value optimization:

For most of today’s compilers, if a return line contains a constructor of an object the code will be optimized to avoid all unnecessary copying - the constructor will be executed directly on the “sum” object.

Common Mistake #5: Using a Reference to a Deleted Resource

These C++ problems happen more often than you may think, and are usually seen in multithreaded applications. Let us consider the following code:

Thread 1:

Thread 2:

Thread 1:

In this example, if both threads used the same connection ID this will result in undefined behavior. Access violation errors are often very hard to find.

In these cases, when more than one thread accesses the same resource it is very risky to keep pointers or references to the resources, because some other thread can delete it. It is much safer to use smart pointers with reference counting, for example shared_ptr from Boost. It uses atomic operations for increasing/decreasing a reference counter, so it is thread safe.

Common Mistake #6: Allowing Exceptions to Leave Destructors

It is not frequently necessary to throw an exception from a destructor. Even then, there is a better way to do that. However, exceptions are mostly not thrown from destructors explicitly. It can happen that a simple command to log a destruction of an object causes an exception throwing. Let’s consider following code:

In the code above, if exception occurs twice, such as during the destruction of both objects, the catch statement is never executed. Because there are two exceptions in parallel, no matter whether they are of the same type or different type the C++ runtime environment does not know how to handle it and calls a terminate function which results in termination of a program’s execution.

So the general rule is: never allow exceptions to leave destructors. Even if it is ugly, potential exception has to be protected like this:

Common Mistake #7: Using “auto_ptr” (Incorrectly)

The auto_ptr template is deprecated from C++11 because of a number of reasons. It is still widely used, since most projects are still being developed in C++98. It has a certain characteristic that is probably not familiar to all C++ developers, and could cause serious problems for somebody who is not careful. Copying of auto_ptr object will transfer an ownership from one object to another. For example, the following code:

… will result in an access violation error. Only object “b” will contain a pointer to the object of Class A, while “a” will be empty. Trying to access a class member of the object “a” will result in an access violation error. There are many ways of using auto_ptr incorrectly. Four very critical things to remember about them are:

  1. Never use auto_ptr inside STL containers. Copying of containers will leave source containers with invalid data. Some STL algorithms can also lead to invalidation of “auto_ptr”s.

  2. Never use auto_ptr as a function argument since this will lead to copying, and leave the value passed to the argument invalid after the function call.

  3. If auto_ptr is used for data members of a class, be sure to make a proper copy inside a copy constructor and an assignment operator, or disallow these operations by making them private.

  4. Whenever possible use some other modern smart pointer instead of auto_ptr.

Common Mistake #8: Using Invalidated Iterators and References

It would be possible to write an entire book on this subject. Every STL container has some specific conditions in which it invalidates iterators and references. It is important to be aware of these details while using any operation. Just like the previous C++ problem, this one can also occur very frequently in multithreaded environments, so it is required to use synchronization mechanisms to avoid it. Lets see the following sequential code as an example:

From a logical point of view the code seems completely fine. However, adding the second element to the vector may result in reallocation of the vector’s memory which will make both the iterator and the reference invalid and result in an access violation error when trying to access them in the last 2 lines.

Common Mistake #9: Passing an Object by Value

You probably know that it is a bad idea to pass objects by value due to its performance impact. Many leave it like that to avoid typing extra characters, or probably think of returning later to do the optimization. It usually never gets done, and as a result leads to lesser performant code and code that is prone to unexpected behavior:

This code will compile. Calling of the “func1” function will create a partial copy of the object “b”, i.e. it will copy only class “A”’s part of the object “b” to the object “a” (“slicing problem”). So inside the function it will also call a method from the class “A” instead of a method from the class “B” which is most likely not what is expected by somebody who calls the function.

Similar problems occur when attempting to catch exceptions. For example:

When an exception of type ExceptionB is thrown from the function “func2” it will be caught by the catch block, but because of the slicing problem only a part from the ExceptionA class will be copied, incorrect method will be called and also re-throwing will throw an incorrect exception to an outside try-catch block.

To summarize, always pass objects by reference, not by value.

Common Mistake #10: Using User Defined Conversions by Constructor and Conversion Operators

Even the user defined conversions are very useful sometimes, but they can lead to unpredicted conversions that are very hard to locate. Let’s say somebody created a library that has a string class:

The first method is intended to create a string of a length n, and the second is intended to create a string containing the given characters. But the problem starts as soon as you have something like this:

In the example above, s1 will become a string of size 123, not a string that contains the characters “123”. The second example contains single quotation marks instead of double quotes (which may happen by accident) which will also result in calling of the first constructor and creating a string with a very big size. These are really simple examples, and there are many more complicated cases that lead to confusion and unpredicted conversions that are very hard to find. There are 2 general rules of how to avoid such problems:

  1. Define a constructor with explicit keyword to disallow implicit conversions.

  2. Instead of using conversion operators, use explicit conversation methods. It requires a little bit more typing, but it is much cleaner to read and can help avoid unpredictable results.


C++ is a powerful language. In fact, many of the applications that you use every day on your computer and have come to love are probably built using C++. As a language, C++ gives a tremendous amount of flexibility to the developer, through some of the most sophisticated features seen in object-oriented programming languages. However, these sophisticated features or flexibilities can often become the cause of confusion and frustration for many developers if not used responsibly. Hopefully this list will help you understand how some of these common mistakes influence what you can achieve with C++.

About the author

Vatroslav Bodrozic, Croatia

member since March 27, 2014

C+++   more

Vatroslav has loved programming since the age of 12, spending nights designing systems in his mind and transferring them into code the next day. After 20+ years of programming experience, he still enjoys and looks for complex, well-designed projects where his passion can be fulfilled. He has 10+ years of professional experience, mostly in C++ on embedded/real-time systems, including a VoIP gateway, automation systems, cryptography, and more. [click to continue...]

Hiring? Meet the Top 10 Freelance C++ Developers for Hire in March 2018

0 Thoughts to “Template Class Assignment Operator Errors

Leave a comment

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *