You can now use nested types in a template parameter list, even if the nested type is defined within the same class that attempts to use the template. For example, given a template list , the following now works:
struct glyph {
...
struct stroke { ... };
list<stroke> l;
...
}
Function pointers now work in template parameter lists. For example, you might want to instantiate a parameterized list class in terms of a pointer to a function like this:
list<int (*)(int, void *)> fnlist;
Nested types are now handled correctly. In particular, there is no longer a limit to how deeply you can nest type definitions.
gnu C++ now conforms to the specifications in Chapter 11 of the arm, ``Member Access Control''.
The ansi C++ committee has introduced a new keyword mutable . gnu C++ supports it. Use mutable to specify that some particular members of a const class are not constant. For example, you can use this to include a cache in a data structure that otherwise represents a read-only database.
Error messages now explicitly specify the declaration, type, or expression that contains an error.
To avoid copying and editing all system include files during gnu C++ installation, the compiler now automatically recognizes system include files as C language definitions, as if they were wrapped in `extern "C" { ... }'.
The compiler checks operator declarations more strictly. For example, you may no longer declare an `operator +' with three arguments.
You can now use template type arguments in the same template parameter list where the type argument is specified (as well as in the template body). For example, you may write
template <class T, T t> class A { ... };
Destructors are now available for all types, even built-in ones; for example, you can call `int::~int'. (Destructors for types like int do not actually do anything, but their existence provides a level of generality that permits smooth template expansion in more cases.)
Enumerated types declared inside a class are now handled correctly.
An argument list for a function may not use an initializer list for its default value. For example, `void foo ( T x = { 1, 2 } )' is not permitted.
A significant amount of work went into improving the ability of the compiler to act accurately on multiple inheritance and virtual functions. Virtual function dispatch has been enhanced as well.
The warning concerning a virtual inheritance environment with a non-virtual destructor has been disabled, since it is not clear that such a warning is warranted.
Until exception handling is fully implemented in the Reno-2 release, use of the identifiers `catch', `throw', or `try' results in the warning:
t.C:1: warning: `catch', `throw', and `try' are all C++ reserved words
When giving a warning or error concerning initialization of a member in a class, the compiler gives the name of the member if it has one.
Detecting friendship between classes is more accurately checked.
The syntaxes of `#pragma implementation "file.h"' and `#pragma interface' are now more strictly controlled. The compiler notices (and warns) when any text follows `file.h' in the implementation pragma, or follows the word `interface'. Any such text is otherwise ignored.
Trying to declare a template on a variable or type is now considered an error, not an unimplemented feature.
When an error occurs involving a template, the compiler attempts to tell you at which point of instantiation the error occurred, in addition to noting the line in the template declaration which had the actual error.
The symbol names for function templates in the resulting assembly file are now encoded according to the arguments, rather than just being emitted as, for example, two definitions of a function `foo'.
Template member functions that are declared static no longer receive a this pointer.
Case labels are no longer allowed to have commas to make up their expressions.
Warnings concerning the shift count of a left or right shift now tell you if it was a `left' or `right' shift.
The compiler now warns when a decimal constant is so large that it becomes unsigned .
Union initializers which are raw constructors are now handled properly.
The compiler no longer gives incorrect errors when initializing a union with an empty initializer list.
Anonymous unions are now correctly used when nested inside a class.
Anonymous unions declared as static class members are now handled properly.
The compiler now notices when a field in a class is declared both as a type and a non-type.
The compiler now warns when a user-defined function shadows a built-in function, rather than emitting an error.
A conflict between two function declarations now produces an error regardless of their language context.
Duplicate definitions of variables with `extern "C"' linkage are no longer considered in error. (Note in C++ linkage---the default---you may not have more than one definition of a variable.)
Referencing a label that is not defined in any function is now an error.
The syntax for pointers to methods has been improved; there are still some minor bugs, but a number of cases should now be accepted by the compiler.
In error messages, arguments are now numbered starting at 1, instead of 0. Therefore, in the function `void foo (int a, int b)', the argument `a' is argument 1, and `b' is argument 2. There is no longer an argument 0.
The tag for an enumerator, rather than its value, used as a default argument is now shown in all error messages. For example, `void foo (enum x (= true))' is shown instead of `void foo (enum x (= 1))'.
The `__asm__' keyword is now accepted by the C++ front-end.
Expressions of the form `foo->~Class()' are now handled properly.
The compiler now gives better warnings for situations which result in integer overflows (e.g., in storage sizes, enumerators, unary expressions, etc).
unsigned bitfields are now promoted to signed int if the field isn't as wide as an int .
Declaration and usage of prefix and postfix `operator ++' and `operator --' are now handled correctly. For example,
class foo
{
public:
operator ++ ();
operator ++ (int);
operator -- ();
operator -- (int);
};
void
f (foo *f)
{
f++; // call f->operator++(int)
++f; // call f->operator++()
f--; // call f->operator++(int)
--f; // call f->operator++()
}
In accordance with arm section 10.1.1, ambiguities and dominance are now handled properly. The rules described in section 10.1.1 are now fully implemented.