What's New in Supported Compilers
Other versions of this page are also available for the following:
.gif "A hyphen indicates that the information in this topic is not relevant for this platform, or that the platform does not support the API that is listed.")
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
8/27/2008
The Windows Embedded CE 6.0 compilers are compatible with the Visual C++ 2005 compiler, except for a few differences that primarily arise from differences in the supported microprocessors.
The following list describes changes in this version that can cause problems. Code that worked in a previous release either might not compile, or might behave differently at run time.
- Pointer-to-members now require qualified name and &
Code written for previous versions of the compiler that just used the method name will now give Compiler Error C3867 or Compiler Warning C4867. This diagnostic is required by Standard C++. In Windows Embedded CE 6.0 and later, the addressof operator (&) must be used with the fully qualified name of the method to create a pointer to a member function.
The lack of the & operator and the fully qualified name of the method can lead to logic bugs in code, due missing parentheses in function calls. If you use a function name without an argument list, it can result in a function pointer which is convertible to several types. This code would have compiled, leading to unexpected behavior at runtime. - Classes must be accessible to a friend declaration
Visual C++ compilers prior to Visual C++ 2005 allowed a friend declaration to a class that was not accessible in the scope of the class containing the declaration. Now, the compiler will give Compiler Error C2248. To resolve this error, change the accessibility of the class specified in the friend declaration. This change was made to comply with the C++ standard. - Explicit specialization not allowed as a copy constructor/copy assignment operator
Code that depends on an explicit template specialization for a copy constructor or copy assignment operator will now get Compiler Error C2299. Standard C++ prohibits this. This change was made for conformance reasons, to make code more portable. - Unspecialized class template can't be used as a template argument in a base class list
Using an unspecialized template class name in the base class list for a class definition will result in Compiler Error C3203. It is illegal to use an unspecialized template class name as a template parameter in a base class list. Explicitly add the template type parameters to the template class name when using it as a template parameter in a base class list. This change was made for conformance reasons, to make code more portable. - A using declaration of nested type no longer allowed
Code that has a using declaration to a nested type will now generate Compiler Error C2885. To resolve fully qualify references to nested types, put the type in a namespace, or create a typedef. This change was made for conformance reasons, to make code more portable. - Enforce parameter checking for Visual C++ attributes
Code that passes named attributes to the attribute constructor in quotes when the type is not a string and without quotes when the type is a string will now give Compiler Error C2065 or Compiler Warning (level 1) C4581. Previously all compiler attributes were parsed as strings, and if needed, the compiler inserted the missing quotes. Attribute support was enhanced by adding parameter checking validation. This will prevent unexpected behavior due to incorrect arguments to an attribute constructor. - Compiler now requires same template specification for multiple declarations of the same type.
If you have a forward declaration of a type so that you can create friends to that type, for example, the template specification of the type must be the same on all declarations for the type. Otherwise, the compiler will issue Compiler Error C2990. - Compiler will not inject int as the default type in declarations
Code that is missing the type in a declaration will no longer default to type int. The compiler will generate Compiler Warning C4430 or Compiler Warning (level 4) C4431. Standard C++ does not support a default int. It is best to fix the source code, but a temporary workaround strategy is to recompile the code with -wd4430. - dynamic_cast has enhanced conformance to the C++ standard.
The C runtime library now does a dynamic_cast runtime check to ensure the compile-time type of the expression being cast refers to a public base class sub-object of either the cast target type (for down-cast) or most-derived object type (for cross-cast). For more information, see Breaking Changes in dynamic_cast. - An rvalue cannot be bound to a non-const reference.
An rvalue cannot be bound to a non-const reference. In previous versions of Visual C++, it was possible to bind an rvalue to a non-const reference in a direct initialization. This code now generates Compiler Warning (level 1) C4350. - Value types no longer have a default constructor emitted, this can cause type initializers to run at different points.
Prior to Visual C++ 2005 static constructors (type initializers) in value types were run when an instance of the value type was created. To ensure that static constructors are run, access a static data member. Not providing a default constructor for value types was done because the common language runtime does not guarantee it will always call a default constructor. Also, not providing a default constructor for value types improves performance. - Native types are private by default outside the assembly
Native types now will not be visible outside the assembly by default. For more information on type visibility outside the assembly, see Type Visibility. This change was primarily driven by the needs of developers using other, case-insensitive languages, when referencing metadata authored in Visual C++.
See Also
Concepts
New Compiler Features
What's New with ATL and MFC