• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Static code analysis and the new language standard C++0x
 

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

on

  • 786 views

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 ...

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.

Statistics

Views

Total Views
786
Views on SlideShare
786
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Static code analysis and the new language standard C++0x Static code analysis and the new language standard C++0x Document Transcript

    • Static code analysis and the newlanguage standard C++0xAuthor: Andrey KarpovDate: 01.04.2010AbstractThe article discusses the new capabilities of C++ language described in the standard C++0x andsupported in Visual Studio 2010. By the example of PVS-Studio we will see how the changes in thelanguage influence static code analysis tools.IntroductionThe new C++ language standard is about to come into our life. They are still calling it C++0x, although itsfinal name seems to be C++11. The new standard is partially supported by modern C++ compilers, forexample, 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 itsspecifics into compilers even when it is accepted.Compiler developers are not the only ones for whom support of the new standard is important. Thelanguage innovations must be quickly provided with support in static source code analyzers. It ispromised that the new standard will provide backward compatibility. The obsolete C++ code is almostguaranteed to be able to be correctly compiled by new compilers without any modifications. But it doesnot mean that a program that does not contain new language constructs still can be processed by astatic analyzer that does not support the new standard C++0x. We got convinced of it in practice whentrying to check a project created in the beta-version of Visual Studio 2010 with PVS-Studio. The point isabout the header files that already use the new language constructs. For example, you may see that theheader file "stddef.h" uses the new operator decltype:namespace std { typedef decltype(__nullptr) nullptr_t; }Such constructs are naturally considered syntactically wrong by an analyzer that does not supportC++0x, and either cause a program abort or incorrect results. It got obvious that we must providesupport for C++0x in PVS-Studio by the moment Visual Studio is released, at least to the extent it is donein this compiler.We may say that we have fulfilled this task with success, and by the moment of writing this article, thenew version PVS-Studio 3.50, integrating both into Visual Studio 2005/2008 and Visual Studio 2010, hasbecome available on our site. Beginning with the version PVS-Studio 3.50, the tool provides support forthe same part of C++0x standard as in Visual Studio 2010. This support is not perfect as, for example, incase of "right-angle brackets", but we will continue the work on developing the support for C++0xstandard in the next versions.In this article, we will study the new features of the language which are supported in the first edition ofVisual 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 inPVS-Studio and how its appearance impacts the library VivaCore.Note. VivaCore is a library of code parsing, analysis and transformation. VivaCore is an open-sourcelibrary that supports the languages C and C++. The product PVS-Studio is based on VivaCore as well asother 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 newstandard in PVS-Studio. The tool PVS-Studio diagnoses 64-bit and parallel OpenMP errors. But since thetopic of moving to 64-bit systems is more relevant at the moment, we will mostly consider examplesthat show how to detect 64-bit errors with PVS-Studio.1. autoLike in C, the type of a variable in C++ must be defined explicitly. But with the appearance of templatetypes and techniques of template metaprogramming in C++ language, it became usual that the type ofan object is not so easy to define. Even in a rather simple case - when searching for array items - weneed to define the type of an iterator in the following way: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 itwill 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 wordauto is replaced with a different one in the new standard. While auto has meant before that a variable iscreated in the stack, and it was implied if you had not specified otherwise (for example, register), now itis analogous to var in C# 3.0. The type of a variable defined as auto is determined by the compiler itselfrelying on what object initializes this variable.We should notice that an auto-variable cannot store values of different types during one instance ofprogram execution. C++ still remains a statically typed language, and by using auto we just tell thecompiler to see to defining the type on its own: once the variable is initialized, its type cannot bechanged.Now the iterator can be defined in this way: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 codesafer. Let us consider an example where auto will be used to make the code safe from the viewpoint of64-bit software development: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 version and failswhen the code is built in the Win64 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-bitprogram, the types string::size_type and unsigned coincide and we get correct results. In the 64-bitprogram, string::size_type and unsigned do not coincide any more. When the substring is not found, thefunction find() returns the value string::npos that equals 0xFFFFFFFFFFFFFFFFui64. This value is cut tothe 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 alwaysreturns true.In this example, the error is not so dangerous because it is detected even by the compiler not to speakof a specialized analyzer Viva64 (included into PVS-Studio).This is how the compiler detects the error:warning C4267: initializing :conversion from size_t to unsigned int, possible loss of dataThis is how Viva64 does it: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 ofa type to store the returned value. The error might appear even because the programmer is reluctant touse 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 writethe following simple and safe code: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 theconclusion - 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 managingthe types. Consider this example: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 arrays size and allocate the necessary memory amount. It is logical toexpect that this function will be able to allocate the necessary memory amount for the array of the size2000*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 anamount 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 mallocis senseless. By the way, the compiler will also warn that this expression is unsafe:warning C4267: initializing :conversion from size_t to int, possible loss of dataRelying on auto, an inaccurate programmer may modify the code in the following way: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 warningany more but the function AllocArray3D will still return NULL.The type of the variable size will automatically turn into size_t. But the overflow occurs when calculatingthe expression "x * y * z". This subexpression has the type int at first and only then it will be extended tosize_t when being multiplied by the variable "objectSize".Now this hidden error may be found only with the help of Viva64 analyzer:V104: Implicit type conversion to memsize type in anarithmetic 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 analyzerViva64 is based on. So, the analyzer must be able to understand that the variable AA has the type int towarn (see V101) the programmer about an extension of the variable AA to the type size_t: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 isstored in the file Lex.cc and has the name tableC0xx. To avoid modifying the obsolete code responsiblefor 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 classesTypeInfo 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 thetype of objects in the coded form (letter x). But this does not let you know what type is actuallyassigned to the variable. That is, VivaCore lacks the functionality that would let you make sure that thevariable 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 ofVivaCore library. The implementation principle lies in additional work of calculating the type inTranslateAssignInitializer method. After the right side of the expression is calculated, the associationbetween the (Bind) name of the variable and the type is replaced with another.2. decltypeIn some cases it is useful to "copy" the type of some object. The key word auto determines the typerelying on the expression used to initialize the variable. If the variable is not initialized, you may use thekey word decltype to determine the type of the expression during compilation. Here is an example ofcode where the variable "value" has the type returned by the function Calc():decltype(Calc()) value;try { value = Calc();}catch(...) { throw;
    • }You may use decltype to define the type: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.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 functionIsPresent searches for an element in a sequence and returns true if it is found: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 morethan 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: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 liesin using decltype: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. Theparsing function rDecltype in the file Parser.cc was added. With the appearance of the new lexeme theyhad 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 unlikelower-case x used for auto). Because of this, the functionality of the classes TypeInfo and Encodingchanged too: for example, the functions WhatIs, IsDecltype, MakePtree.The functionality of calculating the types for decltype operator is implemented in the class Environmentand included into VivaCore library. The type is calculated while writing a new variable/type intoEnvironment (the functions RecordTypedefName, RecordDeclarator, RecordConstantDeclarator). Thefunction FixIfDecltype is responsible for calculating the type.3. R-value referenceIn 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 isalso 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 youtake account of temporary objects and implement the move semantics. For example, if std::vector iscreated as a temporary object or returned from a function, you may simply move all the internal datafrom the reference of the new type when creating a new object. The move constructor std::vectorsimply copies through the reference to a temporary object it has received the pointer of the arraysituated in the reference which is emptied when the copying is over.The move constructor or move operator may be defined in the following way: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 whendefining the type. Therefore, the support of this innovation in VivaCore is very simple. Only the functionoptPtrOperator of Parser class underwent some modifications: we consider & and && equally there.4. Right angle bracketsFrom the viewpoint of C++98 standard, the following construct has a syntactical error:list<vector<string>> lvs;To avoid it, we should input a space between the two right angle brackets:list<vector<string> > lvs;The standard C++0x makes it legal to use double closing brackets when defining template types withoutadding 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 bevery glad to avoid adding a lot of unnecessary spaces.At the moment, parsing of definitions of template types with ">>" is implemented in VivaCore not verywell. In some cases, the analyzer makes mistakes and it seems that we will significantly modify someanalyzers parts responsible for template parsing in time. Until it is done, you will meet the followingugly functions which use heuristic methods to determine if we deal with the shift operator ">>" or partof the definition of the template type "A<B<C>> D": IsTemplateAngleBrackets, isTemplateArgs. Werecommend those, who want to know how to correctly solve this task, to see this document: "RightAngle Brackets (N1757)". In time, we will make processing of right angle brackets in VivaCore better.5. LambdasLambda-expressions in C++ are a brief way of writing anonymous functors (objects that can be used asfunctions). Let us touch upon some history. In C, pointers to a function are used to create functors:/* 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():class compare_class { public: bool operator()(int A, int B) { return (A < B); }};// definition of sorting functiontemplate <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: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 thecompiler automatically. Then we may pass this variable to std::sort. We may also reduce the code a bitmore: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. Thenthere is an optional parameter list and optional type of the returned value. The definition is finishedwith the functions body itself. On the whole, the format of writing lambda-functions is as follows:[ [<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. Todemonstrate using lambda-functions, let us look at the code of a program that prints the strings inincreasing order of their lengths.The program creates an array of strings and an array of indexes. Then the program sorts the stringsindexes so that the strings are arranged according to growth of their lengths: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: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 analysisof common functions. On the whole, analysis of lambda-functions resembles that of common functionswith 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 anexample of code containing a 64-bit error: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 theWin64 mode, the program crashes because of an attempt to access the item with the number0xFFFFFFFF. 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".When checking the code shown above, PVS-Studio generates the diagnostic message:error V108: Incorrect index type: p[not a memsize-type]. Use memsizetype instead.Correspondingly, the analyzer must have parsed the lambda-function and make out the scope ofvariables 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 newfunction rLamdas that participates in the process of building the parse tree. The function is situated inthe class Parser and called from such functions as rInitializeExpr, rFunctionArguments,rCommaExpression. The function rLambdas parses lambda-functions and adds a new type of an objectinto the tree - PtreeLambda. The class PtreeLambda is defined and implemented in the filesPtreeLambda.h and PtreeLambda.Processing of PtreeLambda in the built tree is performed by TranslateLambda function. The whole logicof working with lambda-functions is concentrated in VivaCore. Inside TranslateLambda, you can see thecall of the function GetReturnLambdaFunctionTypeForReturn implemented in PVS-Studios code. Butthis function serves for internal purposes of PVS-Studio and an empty function-stubGetReturnLambdaFunctionTypeForReturn does not impact code parsing in VivaCore at all.6. Suffix return type syntaxThere are cases when it is difficult to determine the type returned by a function. Let us consider anexample of a template function that multiplies two values by each other: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: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 becompiled.To solve this issue, we should use a new syntax of returned values: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 bedetermined or defined later". Unfortunately, this sample cannot be compiled in Visual C++ by themoment of writing this article although it is correct. But we go an alternative way (where we also useSuffix return type syntax):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 parsedby VivaCore library but PVS-Studio does not take into consideration the data types returned by thesefunctions in the analysis. To learn about support of an alternative record of functions in VivaCore library,see the function Parser::rIntegralDeclaration.7. static_assertThe standard C++0x has a new key word static_assert. Its syntax is:static_assert(expression, "error message");If the expression is false, the mentioned error message is displayed and compilation aborts. Let usconsider an example of using static_assert: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: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 veryinteresting and therefore is ignored. In VivaCore, a new lexeme tkSTATIC_ASSERT is added. On meetingthis lexeme, the lexer ignores it and all the parameters referring to the construct static_assert(implemented in the function Lex::ReadToken).8. nullptrThere has been no key word to denote a null pointer before the standard C++0x in C++. To denote it, thenumber 0 was used. But a good style is to use the macro NULL. When opening the macro NULL, it turnsinto 0 and there is no actual difference between them. This is how the macro NULL is defined in VisualStudio:#define NULL 0In some cases, absence of a special key word to define a null pointer was inconvenient and even led toerrors. Consider an example: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 is0 that will be put instead of NULL and that will have the type int. When launching the program you willsee on the screen:Foo(int a)Foo(int a)To eliminate such situations, the key word nullptr was introduced into C++0x. The constant nullptr hasthe type nullptr_t and is implicitly converted to any pointer type or a pointer to class members. Theconstant 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: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: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 besupported when parsing the code. For this purpose, a new lexeme tkNULLPTR was added in VivaCore aswell 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 *". Fromthe viewpoint of existing tasks of code analysis in PVS-Studio, it is quite enough.9. New standard classesThe standard C++0x introduces new standard classes referring to namespace std. Some of these classesare 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 orVivaCore library.10. New trends in development of static code analyzersAt 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 eliminatingold 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 constructsis implemented much worse or not implemented at all. Consider a small sample showing the use of anuninitialized variable:{ 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 withthe 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 sometime to implement such diagnosis.We may expect a new round in development of static analyzers concerning the topic of searching forpotentially 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 paralleltechnologies by this term. In the future, we plan to carry out an investigation into the question whatpotential issues one may expect using C++0x. If there are a lot of traps, perhaps we will start developinga new tool to diagnose them.SummaryWe think that C++0x brings many good features. Obsolete code does not demand an immediateupgrading, although it may be modified during refactoring in time. What the new code is concerned, wemay write it already with the new constructs. So, it seems reasonable to start employing C++0x rightnow.References 1. Bjarne Stroustrup. C++0x - the next ISO C++ standard. http://www.viva64.com/go.php?url=304
    • 2. Visual C++ Team Blog. Rvalue References: C++0x Features in VC10, Part 2. http://www.viva64.com/go.php?url=3053. Wikipedia. C++0x. http://www.viva64.com/go.php?url=3014. Herb Sutter. Trip Report: March 2010 ISO C++ Standards Meeting. http://www.viva64.com/go.php?url=308