# Static code analysis and the new language standard C\+\+0x

The article discusses the new capabilities of C\+\+ language described in the standard C\+\+0x and supported in Visual Studio 2010\. By the example of PVS\-Studio we will see how the changes in the language influence static code analysis tools\.

## Introduction

The new C\+\+ language standard is about to come into our life\. They are still calling it _C\+\+0x_, although its final name seems to be _C\+\+11_\. The new standard is partially supported by modern C\+\+ compilers, for example, Intel C\+\+ and Visual C\+\+\. This support is far from being full\-fledged and it is quite clear why\. First, the standard has not been accepted yet, and second, it will take some time to introduce its specifics into compilers even when it is accepted\.

Compiler developers are not the only ones for whom support of the new standard is important\. The language innovations must be quickly provided with support in static source code analyzers\. It is promised that the new standard will provide backward compatibility\. The obsolete C\+\+ code is almost guaranteed to be able to be correctly compiled by new compilers without any modifications\. But it does not mean that a program that does not contain new language constructs still can be processed by a static analyzer that does not support the new standard _C\+\+0x_\. We got convinced of it in practice when trying to check a project created in the beta\-version of Visual Studio 2010 with [PVS\-Studio](https://pvs-studio.com/en/pvs-studio/)\. The point is about the header files that already use the new language constructs\. For example, you may see that the header file "stddef\.h" uses the new operator _decltype_:

```cpp
namespace std { typedef decltype(__nullptr) nullptr_t; }
```

Such constructs are naturally considered syntactically wrong by an analyzer that does not support _C\+\+0x_, and either cause a program abort or incorrect results\. It got obvious that we must provide support for _C\+\+0x_ in PVS\-Studio by the moment Visual Studio is released, at least to the extent it is done in this compiler\.

We may say that we have fulfilled this task with success, and by the moment of writing this article, the new version PVS\-Studio 3\.50, integrating both into Visual Studio 2005/2008 and Visual Studio 2010, has become available on our site\. Beginning with the version PVS\-Studio 3\.50, the tool provides support for the same part of _C\+\+0x_ standard as in Visual Studio 2010\. This support is not perfect as, for example, in case of "right\-angle brackets", but we will continue the work on developing the support for _C\+\+0x_ standard in the next versions\.

In this article, we will study the new features of the language which are supported in the first edition of Visual Studio 2010\. We will look at these features from different viewpoints: what this or that new ability is about, if there is a relation to 64\-bit errors, how the new language construct is supported in PVS\-Studio and how its appearance impacts the library [VivaCore](https://pvs-studio.com/en/pvs-studio/)\.

_Note\. VivaCore is a library of code parsing, analysis and transformation\. VivaCore is an open\-source library that supports the languages C and C\+\+\. The product PVS\-Studio is based on VivaCore as well as other program projects may be created relying on this library_\.

The article we want to present may be called a report on the investigation and support of the new standard in PVS\-Studio\. The tool PVS\-Studio diagnoses 64\-bit and parallel [OpenMP](https://pvs-studio.com/en/blog/posts/a0057/) errors\. But since the topic of moving to 64\-bit systems is more relevant at the moment, we will mostly consider examples that show how to detect [64\-bit errors](https://pvs-studio.com/en/blog/terms/0002/) with PVS\-Studio\.

## 1\. auto

Like in C, the type of a variable in C\+\+ must be defined explicitly\. But with the appearance of template types and techniques of template metaprogramming in C\+\+ language, it became usual that the type of an object is not so easy to define\. Even in a rather simple case \- when searching for array items \- we need to define the type of an iterator in the following way:

```cpp
for (vector<int>::iterator itr = myvec.begin(); 
     itr != myvec.end(); 
     ++itr)
```

Such constructs are very long and cumbersome\. To make the record briefer, we may use _typedef_ but it will spawn new entities and do little for the purpose of convenience\.

_C\+\+0x_ offers its own technique to make this issue a bit less complicated\. The meaning of the key word _auto_ is replaced with a different one in the new standard\. While _auto_ has meant before that a variable is created in the stack, and it was implied if you had not specified otherwise \(for example, _register_\), now it is analogous to _var_ in C\# 3\.0\. The type of a variable defined as _auto_ is determined by the compiler itself relying on what object initializes this variable\.

We should notice that an _auto_\-variable cannot store values of different types during one instance of program execution\. C\+\+ still remains a statically typed language, and by using _auto_ we just tell the compiler to see to defining the type on its own: once the variable is initialized, its type cannot be changed\.

Now the iterator can be defined in this way:

```cpp
for (auto itr = myvec.begin(); itr != myvec.end(); ++itr)
```

Besides mere convenience of writing the code and its simplification, the key word _auto_ makes the code safer\. Let us consider an example where _auto_ will be used to make the code safe from the viewpoint of 64\-bit software development:

```cpp
bool Find_Incorrect(const string *arrStr, size_t n)
{
  for (size_t i = 0; i != n; ++i)
  {
    unsigned n = arrStr[i].find("ABC");
    if (n != string::npos)
      return true;
  }
  return false;
};
```

This code has a 64\-bit error: the function behaves correctly when compiling the [Win32](https://pvs-studio.com/en/blog/terms/0054/) version and fails when the code is built in the [Win64](https://pvs-studio.com/en/blog/terms/0055/) mode\. The error is in using the type _unsigned_ for the variable "n", although the type _string::size\_type_ must be used which is returned by the function _find\(\)_\. In the 32\-bit program, the types _string::size\_type_ and _unsigned_ coincide and we get correct results\. In the 64\-bit program, _string::size\_type_ and _unsigned_ do not coincide any more\. When the substring is not found, the function _find\(\)_ returns the value _string::npos_ that equals 0xFFFFFFFFFFFFFFFFui64\. This value is cut to the value 0xFFFFFFFFu and placed into a 32\-bit variable\. As a result, the condition 0xFFFFFFFFu \!\= 0xFFFFFFFFFFFFFFFFui64 is true and we have the situation when the function _Find\_Incorrect_ always returns _true_\.

In this example, the error is not so dangerous because it is detected even by the compiler not to speak of a specialized analyzer Viva64 \(included into PVS\-Studio\)\.

This is how the compiler detects the error:

```cpp
warning C4267: 'initializing' : 
conversion from 'size_t' to 'unsigned int', possible loss of data
```

This is how Viva64 does it:

```cpp
V103: Implicit type conversion from memsize to 32-bit type.
```

What is most important, this error is quite possible and often occurs in code due to inaccurate choice of a type to store the returned value\. The error might appear even because the programmer is reluctant to use a cumbersome construct of the _string::size\_type_ kind\.

Now we can easily avoid such errors without overloading the code\. Using the type _auto_, we may write the following simple and safe code:

```cpp
auto n = arrStr[i].find("ABC");
if (n != string::npos)
  return true;
```

The error disappeared by itself\. The code has not become more complicated or less effective\. Here is the conclusion \- it is reasonable in many cases to use _auto_\.

The key word _auto_ will reduce the number of 64\-bit errors or let you eliminate them with more grace\. But _auto_ does not in itself guarantee that all the 64\-bit errors will be eliminated\! It is just one more language tool that serves to make programmers' life easier but not to take all their work of managing the types\. Consider this example:

```cpp
void *AllocArray3D(int x, int y, int z,
                   size_t objectSize)
{
  int size = x * y * z * objectSize;
  return malloc(size);
}
```

The function must calculate the array's size and allocate the necessary memory amount\. It is logical to expect that this function will be able to allocate the necessary memory amount for the array of the size 2000\*2000\*2000 of _double_ type in the 64\-bit environment\. But the call of the "AllocArray3D\(2000, 2000, 2000, sizeof\(double\)\);" kind will always return NULL, as if it is impossible to allocate such an amount of memory\. The true reason for this is the overflow in the expression "int size \= x \* y \* z \* sizeof\(double\)"\. The variable _size_ takes the value \-424509440 and the further call of the function _malloc_ is senseless\. By the way, the compiler will also warn that this expression is unsafe:

```cpp
warning C4267: 'initializing' : 
conversion from 'size_t' to 'int', possible loss of data
```

Relying on _auto_, an inaccurate programmer may modify the code in the following way:

```cpp
void *AllocArray3D(int x, int y, int z,
                   size_t objectSize)
{
  auto size = x * y * z * objectSize;
  return (double *)malloc(size);
}
```

But it will not eliminate the error at all and will only hide it\. The compiler will not generate a warning any more but the function _AllocArray3D_ will still return NULL\.

The type of the variable _size_ will automatically turn into [size\_t](https://pvs-studio.com/en/blog/terms/0044/)\. But the overflow occurs when calculating the expression "x \* y \* z"\. This subexpression has the type _int_ at first and only then it will be extended to _size\_t_ when being multiplied by the variable "objectSize"\.

Now this hidden error may be found only with the help of Viva64 analyzer:

```cpp
V104: Implicit type conversion to memsize type in an 
arithmetic expression.
```

The conclusion \- you must be attentive even if you use _auto_\.

Let us now briefly look how the new key word is supported in the library VivaCore the static analyzer Viva64 is based on\. So, the analyzer must be able to understand that the variable _AA_ has the type _int_ to warn \(see [V101](https://pvs-studio.com/en/docs/warnings/v101/)\) the programmer about an extension of the variable _AA_ to the type _size\_t_:

```cpp
void Foo(int X, int Y)
{
  auto AA = X * Y;
  size_t BB = AA; //V101
}
```

First of all, a new table of lexemes was composed that included the new _C\+\+0x_ key words\. This table is stored in the file Lex\.cc and has the name tableC0xx\. To avoid modifying the obsolete code responsible for processing the lexeme "auto" \(tkAUTO\), it got the name tkAUTOcpp0x in this table\.

With the appearance of the new lexeme, the following functions were modified: isTypeToken, optIntegralTypeOrClassSpec\. A new class LeafAUTOc0xx appeared\. TypeInfoId has a new object class \- AutoDecltypeType\.

To code the type _auto_, the letter 'x' was chosen and it was reflected in the functions of the classes TypeInfo and Encoding\. These are, for example, such functions as IsAutoCpp0x, MakePtree\.

These corrections let you parse the code with the key word _auto_ that has a new meaning and save the type of objects in the coded form \(letter 'x'\)\. But this does not let you know what type is actually assigned to the variable\. That is, VivaCore lacks the functionality that would let you make sure that the variable _AA_ in the expression "auto AA \= X \* Y" will have the type _int_\.

This functionality is implemented in the source code of Viva64 and cannot be integrated into the code of VivaCore library\. The implementation principle lies in additional work of calculating the type in TranslateAssignInitializer method\. After the right side of the expression is calculated, the association between the \(Bind\) name of the variable and the type is replaced with another\.

## 2\. decltype

In some cases it is useful to "copy" the type of some object\. The key word _auto_ determines the type relying on the expression used to initialize the variable\. If the variable is not initialized, you may use the key word _decltype_ to determine the type of the expression during compilation\. Here is an example of code where the variable "value" has the type returned by the function _Calc\(\)_:

```cpp
decltype(Calc()) value;
try {
  value = Calc(); 
}
catch(...) {
  throw;
}
```

You may use _decltype_ to define the type:

```cpp
void f(const vector<int>& a,
       vector<float>& b)
{
  typedef decltype(a[0]*b[0]) Tmp;
  for (int i=0; i<b.size(); ++i)
  {
    Tmp* p = new Tmp(a[i]*b[i]);
    // ...
  }
}
```

Keep in mind that the type defined with _decltype_ may differ from that defined with _auto_\.

```cpp
const std::vector<int> v(1);
auto a = v[0];
decltype(v[0]) b = 1;
// type a - int  
// type b - const int& (returned value
// std::vector<int>::operator[](size_type) const)
```

Let us look at another sample where _decltype_ can be useful from the viewpoint of 64 bits\. The function _IsPresent_ searches for an element in a sequence and returns _true_ if it is found:

```cpp
bool IsPresent(char *array,
               size_t arraySize,
               char key)
{
  for (unsigned i = 0; i < arraySize; i++) 
    if (array[i] == key)
      return true;
  return false;
}
```

This function cannot work on a 64\-bit system with large arrays\. If the variable _arraySize_ has a value more than UINT\_MAX, the condition "i < arraySize" will never be fulfilled and an eternal loop will occur\.

If we use the key word _auto_, it will not change anything:

```cpp
for (auto i = 0; i < arraySize; i++) 
  if (array[i] == key)
    return true;
```

The variable "i" will have the type _int_ because 0 has _int_ type\. The appropriate correction of the error lies in using _decltype_:

```cpp
for (decltype(arraySize) i = 0; i < arraySize; i++) 
  if (array[i] == key)
    return true;
```

Now the counter "i" has the type _size\_t_ as well as the variable _arraySize_\.

_decltype_ in VivaCore library is supported much like _auto_\. A new lexeme tkDECLTYPE was added\. The parsing function rDecltype in the file Parser\.cc was added\. With the appearance of the new lexeme they had to modify the function optIntegralTypeOrClassSpec\. A new class LeafDECLTYPE appeared\.

To code the type returned by the operator _decltype_, the character 'X' was chosen \(capital 'X' unlike lower\-case 'x' used for _auto_\)\. Because of this, the functionality of the classes TypeInfo and Encoding changed too: for example, the functions WhatIs, IsDecltype, MakePtree\.

The functionality of calculating the types for _decltype_ operator is implemented in the class Environment and included into VivaCore library\. The type is calculated while writing a new variable/type into Environment \(the functions RecordTypedefName, RecordDeclarator, RecordConstantDeclarator\)\. The function FixIfDecltype is responsible for calculating the type\.

## 3\. R\-value reference

In the standard _C\+\+98_, temporary objects can be passed into functions but only as a constant reference \(_const &_\)\. Therefore, a function cannot determine if it is a temporary object or a common one which is also passed as _const &_\.

In _C\+\+0x_, a new type of references is added \- R\-value reference\. It is defined in the following way: "TYPE\_NAME &&"\. It may be used as a non\-constant, legally modified object\. This innovation lets you take account of temporary objects and implement the move semantics\. For example, if _std::vector_ is created as a temporary object or returned from a function, you may simply move all the internal data from the reference of the new type when creating a new object\. The move constructor _std::vector_ simply copies through the reference to a temporary object it has received the pointer of the array situated in the reference which is emptied when the copying is over\.

The move constructor or move operator may be defined in the following way:

```cpp
template<class T> class vector {
  // ...
  vector(const vector&); // copy constructor
  vector(vector&&);      // move constructor
  vector& operator=(const vector&); // copy assignment
  vector& operator=(vector&&);      // move assignment
};
```

From the viewpoint of analyzing 64\-bit errors in code, it does not matter if '&' or '&&' is processed when defining the type\. Therefore, the support of this innovation in VivaCore is very simple\. Only the function optPtrOperator of Parser class underwent some modifications: we consider '&' and '&&' equally there\.

## 4\. Right angle brackets

From the viewpoint of _C\+\+98_ standard, the following construct has a syntactical error:

```cpp
list<vector<string>> lvs;
```

To avoid it, we should input a space between the two right angle brackets:

```cpp
list<vector<string> > lvs;
```

The standard _C\+\+0x_ makes it legal to use double closing brackets when defining template types without adding a space between them\. As a result, it enables us to write a bit more elegant code\.

It is important to implement support for this innovation in static analyzers because developers will be very glad to avoid adding a lot of unnecessary spaces\.

At the moment, parsing of definitions of template types with "\>\>" is implemented in VivaCore not very well\. In some cases, the analyzer makes mistakes and it seems that we will significantly modify some analyzer's parts responsible for template parsing in time\. Until it is done, you will meet the following ugly functions which use heuristic methods to determine if we deal with the shift operator "\>\>" or part of the definition of the template type "A<B<C\>\> D": IsTemplateAngleBrackets, isTemplateArgs\. We recommend those, who want to know how to correctly solve this task, to see this document: "[Right Angle Brackets \(N1757\)](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1757.html)"\. In time, we will make processing of right angle brackets in VivaCore better\.

## 5\. Lambdas

Lambda\-expressions in C\+\+ are a brief way of writing anonymous functors \(objects that can be used as functions\)\. Let us touch upon some history\. In C, pointers to a function are used to create functors:

```cpp
/* callback-function */
int compare_function(int A, int B) {
  return A < B;
}
 
/* definition of sorting function */
void mysort(int* begin_items,
            int num_items,
            int (*cmpfunc)(int, int));
 
int main(void) {
    int items[] = {4, 3, 1, 2};
    mysort(items,
           sizeof(items)/sizeof(int),
           compare_function);
    return 0;
}
```

Earlier, the functor in C\+\+ was created with the help of a class with an overloaded _operator\(\)_:

```cpp
class compare_class {
  public:
  bool operator()(int A, int B) {
    return (A < B);
  }
};
// definition of sorting function
template <class ComparisonFunctor> 
void mysort (int* begin_items,
             int num_items,
             ComparisonFunctor c);
 
int main() {
    int items[] = {4, 3, 1, 2};
    compare_class functor;
    mysort(items,
    sizeof(items)/sizeof(int),
    functor);
}
```

In _C\+\+0x_, we are enabled to define the functor even more elegantly:

```cpp
auto compare_function = [](char a, char b)
  { return a < b; };
char Str[] = "cwgaopzq";
std::sort(Str,
          Str + strlen(Str),
          compare_function);
cout << Str << endl;
```

We create a variable _compare\_function_ which is a functor and whose type is determined by the compiler automatically\. Then we may pass this variable to _std::sort_\. We may also reduce the code a bit more:

```cpp
char Str[] = "cwgaopzq";
std::sort(
  Str,
  Str + strlen(Str),
  [](char a, char b) {return a < b;}
);
cout << Str << endl;
```

Here "\[\]\(char a, char b\) \{return a < b;\}" is that very lambda\-function\.

A lambda\-expression always begins with brackets \[\] in which you may specify the capture list\. Then there is an optional parameter list and optional type of the returned value\. The definition is finished with the function's body itself\. On the whole, the format of writing lambda\-functions is as follows:

```cpp
'[' [<capture_list>] ']'
[ '(' <parameter_list> ')' ['mutable' ] ]
[ 'throw' '(' [<exception_types>] ')' ]
[ '->' <returned_value_type> ]
'{' [<function_body>] '}'
```

_Note\. Specification of exceptions in common and lambda\-functions is considered obsolete nowadays\. There is a new key word noexcept introduced but this innovation has not been supported in Visual C\+\+ yet\._

The capture list specifies what objects from the exterior scope a lambda\-function is allowed to access:

* \[\] \- without capturing variables from the exterior scope;
* \[\=\] \- all the variables are captured by value;
* \[&\] \- all the variables are captured by reference;
* \[x, y\] \- x and y are captured by value;
* \[&x, &y\] \- x and y are captured by reference;
* \[in, &out\] \- capturing _in_ by value and _out_ by reference;
* \[\=, &out1, &out2\] \- capturing all the variables by value except for _out1_ and _out2_ which are captured by reference;
* \[&, x, &y\] \- capturing all the variables by reference except for x\.

Unfortunately, it is impossible to cover lambda\-functions very thoroughly within the scope of this article\. You may read about them in detail in the sources given in the references at the end of this article\. To demonstrate using lambda\-functions, let us look at the code of a program that prints the strings in increasing order of their lengths\.

The program creates an array of strings and an array of indexes\. Then the program sorts the strings' indexes so that the strings are arranged according to growth of their lengths:

```cpp
int _tmain(int, _TCHAR*[])
{
  vector<string> strings;
  strings.push_back("lambdas");
  strings.push_back("decltype");
  strings.push_back("auto");
  strings.push_back("static_assert");
  strings.push_back("nullptr");
  vector<size_t> indices;
  size_t k = 0;
  generate_n(back_inserter(indices),
             strings.size(),
             [&k]() { return k++; });
  sort(indices.begin(),
       indices.end(),
       [&](ptrdiff_t i1, ptrdiff_t i2)
       { return strings[i1].length() <
                strings[i2].length(); });
  for_each(indices.begin(),
           indices.end(),
           [&strings](const size_t i)
           { cout << strings[i] << endl; });
  return 0;
}
```

_Note\. According to C\+\+0x, you may initialize arrays std::vector in the following way:_

```cpp
vector<size_t> indices = {0,1,2,3,4};
```

_But Visual Studio 2010 has no support for such constructs yet\._

The quality of analysis of lambda\-functions in static analyzers must correspond to the quality of analysis of common functions\. On the whole, analysis of lambda\-functions resembles that of common functions with the exception that lambda\-functions have a different scope\.

In PVS\-Studio, we implemented the complete diagnosis of errors in lambda\-functions\. Let us consider an example of code containing a 64\-bit error:

```cpp
int a = -1;
unsigned b = 0;
const char str[] = "Viva64";
const char *p = str + 1;
auto lambdaFoo = [&]() -> char
  {
    return p[a+b];
  };
cout << lambdaFoo() << endl;
```

This code works when compiling the program in the Win32 mode and displays the letter 'V'\. In the Win64 mode, the program crashes because of an attempt to access the item with the number 0xFFFFFFFF\. To learn more about this kind of errors, see the lessons on development of 64\-bit C/C\+\+ applications \- "[Lesson 13\. Pattern 5\. Address arithmetic](https://pvs-studio.com/en/blog/lessons/0013/)"\.

When checking the code shown above, PVS\-Studio generates the diagnostic message:

```cpp
error V108: Incorrect index type: p[not a memsize-type]. Use memsize
  type instead.
```

Correspondingly, the analyzer must have parsed the lambda\-function and make out the scope of variables to do this\. It is a difficult yet necessary functionality\.

The most significant modifications in VivaCore are related to lambda\-function support\. It is a new function rLamdas that participates in the process of building the [parse tree](https://pvs-studio.com/en/blog/terms/0039/)\. The function is situated in the class Parser and called from such functions as rInitializeExpr, rFunctionArguments, rCommaExpression\. The function rLambdas parses lambda\-functions and adds a new type of an object into the tree \- PtreeLambda\. The class PtreeLambda is defined and implemented in the files PtreeLambda\.h and PtreeLambda\.

Processing of PtreeLambda in the built tree is performed by TranslateLambda function\. The whole logic of working with lambda\-functions is concentrated in VivaCore\. Inside TranslateLambda, you can see the call of the function GetReturnLambdaFunctionTypeForReturn implemented in PVS\-Studio's code\. But this function serves for internal purposes of PVS\-Studio and an empty function\-stub GetReturnLambdaFunctionTypeForReturn does not impact code parsing in VivaCore at all\.

## 6\. Suffix return type syntax

There are cases when it is difficult to determine the type returned by a function\. Let us consider an example of a template function that multiplies two values by each other:

```cpp
template<class T, class U>
??? mul(T x, U y)
{
  return x*y;
}
```

The returned type must be the type of the expression "x\*y"\. But it is not clear what to write instead of "???"\. The first idea is to use _decltype_:

```cpp
template<class T, class U>
decltype(x*y) mul(T x, U y) //Scope problem!
{
  return x*y;
}
```

The variables "x" and "y" are defined after "decltype\(x\*y\)" and this code, unfortunately, cannot be compiled\.

To solve this issue, we should use a new syntax of returned values:

```cpp
template<class T, class U>
[] mul(T x, U y) -> decltype(x*y)
{
  return x*y;
}
```

Using the brackets \[\], we spawn a lambda\-function here and say that "the returned type will be determined or defined later"\. Unfortunately, this sample cannot be compiled in Visual C\+\+ by the moment of writing this article although it is correct\. But we go an alternative way \(where we also use Suffix return type syntax\):

```cpp
template<class T, class U>
auto mul(T x, U y) -> decltype(x*y)
{
  return x*y;
}
```

This code will be successfully built by Visual C\+\+ and we will get the needed result\.

The version PVS\-Studio 3\.50 supports the new function format only partially\. Constructs are fully parsed by VivaCore library but PVS\-Studio does not take into consideration the data types returned by these functions in the analysis\. To learn about support of an alternative record of functions in VivaCore library, see the function Parser::rIntegralDeclaration\.

## 7\. static\_assert

The standard _C\+\+0x_ has a new key word _static\_assert_\. Its syntax is:

```cpp
static_assert(expression, "error message");
```

If the expression is _false_, the mentioned error message is displayed and compilation aborts\. Let us consider an example of using _static\_assert_:

```cpp
template <unsigned n>
struct MyStruct
{
  static_assert(n > 5, "N must be more 5");
};
MyStruct<3> obj;
```

When compiling this code, Visual C\+\+ compiler will display the message:

```cpp
error C2338: N must be more 5
  xx.cpp(33) : see reference to class template
  instantiation 'MyStruct<n>' being compiled 
  with
  [
    n=3
  ]
```

From the viewpoint of code analysis performed by PVS\-Studio, the construct _static\_assert_ is not very interesting and therefore is ignored\. In VivaCore, a new lexeme tkSTATIC\_ASSERT is added\. On meeting this lexeme, the lexer ignores it and all the parameters referring to the construct _static\_assert_ \(implemented in the function Lex::ReadToken\)\.

## 8\. nullptr

There has been no key word to denote a null pointer before the standard _C\+\+0x_ in C\+\+\. To denote it, the number 0 was used\. But a good style is to use the macro NULL\. When opening the macro NULL, it turns into 0 and there is no actual difference between them\. This is how the macro NULL is defined in Visual Studio:

```cpp
#define NULL    0
```

In some cases, absence of a special key word to define a null pointer was inconvenient and even led to errors\. Consider an example:

```cpp
void Foo(int a)
{ cout << "Foo(int a)" << endl; }
void Foo(char *a)
{ cout << "Foo(char *a)" << endl; }
int _tmain(int, _TCHAR*[])
{
  Foo(0);
  Foo(NULL);
  return 0;
}
```

Although the programmer expects that different _Foo_ functions will be called in this code, it is wrong\. It is 0 that will be put instead of NULL and that will have the type _int_\. When launching the program you will see on the screen:

```cpp
Foo(int a)
Foo(int a)
```

To eliminate such situations, the key word _nullptr_ was introduced into _C\+\+0x_\. The constant _nullptr_ has the type _nullptr\_t_ and is implicitly converted to any pointer type or a pointer to class members\. The constant _nullptr_ cannot be implicitly converted to integer data types except for _bool_ type\.

Let us return to our example and add the call of the function _Foo_ with the argument _nullptr_:

```cpp
void Foo(int a)
{ cout << "Foo(int a)" << endl; }
void Foo(char *a)
{ cout << "Foo(char *a)" << endl; }
int _tmain(int, _TCHAR*[])
{
  Foo(0);
  Foo(NULL);
  Foo(nullptr);
  return 0;
}
```

Now you will see:

```cpp
Foo(int a)
Foo(int a)
Foo(char *a)
```

Although the key word _nullptr_ is not relevant from the viewpoint of searching for 64\-bit error, it must be supported when parsing the code\. For this purpose, a new lexeme tkNULLPTR was added in VivaCore as well as the class LeafNULLPTR\. Objects of LeafNULLPTR type are created in the function rPrimaryExpr\. When calling the function LeafNULLPTR::Typeof, the type "nullptr" is coded as "Pv", i\.e\. "void \*"\. From the viewpoint of existing tasks of code analysis in PVS\-Studio, it is quite enough\.

## 9\. New standard classes

The standard _C\+\+0x_ introduces new standard classes referring to _namespace std_\. Some of these classes are already supported in Visaul Studio 2010, for example:

* std::array;
* std::shared\_ptr;
* std::regex\.

Since these entities are usual template classes, they do not demand any modification of PVS\-Studio or VivaCore library\.

## 10\. New trends in development of static code analyzers

At the end of our article, I would like to mention one interesting thing related to using _C\+\+0x_ standard\. On the one hand, the new features of the language make code safer and more effective by eliminating old drawbacks, but on the other hand, they create new unknown traps the programmer might fall into\. However, I cannot tell you anything about them yet\.

But one might fall into already known traps as well because their diagnosis in the new _C\+\+0x_ constructs is implemented much worse or not implemented at all\. Consider a small sample showing the use of an uninitialized variable:

```cpp
{
  int x;
  std::vector<int> A(10);
  A[0] = x; // Warning C4700
}
{
  int x;
  std::vector<int> A(10);
  std::for_each(A.begin(), A.end(),
    [x](int &y)
    { y = x; } // No Warning
  );
}
```

The programmer might hope to get a warning from the compiler in both cases\. But in the example with the lambda\-function, there will be no diagnostic message \(it was tried on Visual Studio 2010 RC, /W4\) \- like there have not been many other warnings about various dangerous situations before\. It needs some time to implement such diagnosis\.

We may expect a new round in development of static analyzers concerning the topic of searching for potentially dangerous constructs that occur when using _C\+\+0x_ constructs\. We position our product PVS\-Studio as a tool to test contemporary programs\. At the moment, we understand 64\-bit and parallel technologies by this term\. In the future, we plan to carry out an investigation into the question what potential issues one may expect using _C\+\+0x_\. If there are a lot of traps, perhaps we will start developing a new tool to diagnose them\.

## Summary

We think that _C\+\+0x_ brings many good features\. Obsolete code does not demand an immediate upgrading, although it may be modified during refactoring in time\. What the new code is concerned, we may write it already with the new constructs\. So, it seems reasonable to start employing _C\+\+0x_ right now\.

## References

1. Bjarne Stroustrup\. C\+\+0x — the next ISO C\+\+ standard\. 
1. Wikipedia\. [C\+\+0x\.](https://en.wikipedia.org/wiki/C%2B%2B11)
1. Herb Sutter\. [Trip Report: March 2010 ISO C\+\+ Standards Meeting\.](https://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/)