... ... the author of a library can detect run-time errors but does not in general have any idea what to do about them. The user of a library may know how to cope with such errors but cannot detect them - or else they would have been handled in the users code and not left for the library to find. The notion of an exception is provided to help deal with such problems.

The fundamental idea is that a function finds a problem it cannot cope with throws an exception, hoping that its (direct or indirect) caller can handle the problem. A function that wants to handle that kind of problems can indicate that it is willing to catch that exception.

A string literal is not acceptable as a template argument.

An integer template argument must be a constant.

The 'template <class C>' prefix specifies that a template is declared and a type argument C will be used in the declaration. After its introduction, C is used exactly like other type names. The scope of C extends to the end of the declaration prefixed by 'template <class C>'. Note that 'template <class C>' says that C is a type name; it need not be a name of a class.

Title says all.

Finding the right version to call from a set of overloaded functions is done by looking for a best match between the type of the argument expression and the parameters (formal arguments) of the functions. To approximate our notions of what is reasonable, a series of critieria are tried in order:

[1] exact match; that is, matching with no or only trivial conversions(for example, array name to pointer, function name to pointer to function, and T to const T)

[2] Match using promotions; that is integral promotions(bool to int, char to int, short to int, and their unsigned counterpart), float to double, and double to long double.

[3] Match using standard conversion. (for example, int to double, double to int, Derived* to Base*, T* to void*, int to unsigned int)

[4] Match using user-defined conversions

[5]Match using the ellipsis ... in a function declaration

An operator is either a member of a class or defined in some namespace.

Operators defined in namespaces can be found based on their operand types just like functions can be found based on their argument types.

For binary operator @, x@y where x is of type X and y is of type Y is resoved like this:

[1] If X is a class, determine whether class X or a base of X defines operator @ as a member; if so, that is the @ try to use.

[2] Otherwise,

    ---- look for declaration of @ in the context surrounding x@y;

    ---- if X is defined in namespace N, look for declaration of @ in N;

    ---- if Y is defined in namespace M, look for declaration of @ in M.

In either case, declarations for several operator@s may be found and overload resolution rules are used to find the best match, if any. This lookup machanism is applied only if the operator has at least one operand of a user-defined type. Therefore, user-defined conversions will be considered.

An operator must either be a member or take at least one argument of a user-defined type(functions redefining new and delete operators need not).

This rule ensures that a user cannot change the meaning of an expression unless the expression contains an object of a user-defined type.

In particular, it is not possible to define an operator function that operate exclusively on pointers. This ensures that C++ is extensible but not mutable(with the exception of operator =, & and , for class objects).

An operator function intended to accept a basic type as it's first operand can not be a member function. For example, ... ...

Enumerations are user-defined types so that we can define operators for them.

Every expression is checked for ambiguities.

It not possibe to define new operator tokens, but you can use the function call notation when this set of operators is not adequate.

These restrictions may seem Draconian, but more flexible rules may easily lead to ambiguities.

An operator can be declared only for the syntax defined for it in the grammar.

Predefined meaning of user-defined operators

Only a few assumption are made about the meaning of a user-defined operator. In particular, operator=, operator[], operator(), operator-> must be nonstatic member functions; this ensures their first operands will be lvalues.

Because of historical accident, the operator= (assignment), &(address of), and , (sequencing) have predefined meanings when applied to class objects. These predefined meanings can be made inaccessible to general users by making them private.

Implicit conversion can be suppressed by declaring a constructor explicit.