Aktualisierung des Lebenszeitprofils in Visual Studio 2019 Vorschau 2

Das Lebenszeitprofil der C ++ - Kernrichtlinien , das Teil der C ++ - Kernrichtlinien ist , zielt darauf ab, Lebensdauerprobleme wie baumelnde Zeiger und Referenzen in C ++ - Code zu erkennen. Es verwendet die bereits in der Quelle vorhandenen Typinformationen zusammen mit einigen einfachen Verträgen zwischen Funktionen, um Fehler zur Kompilierungszeit mit minimaler Annotation zu erkennen.

Dies sind die Grundverträge, für die das Profil Code erwartet:

1. Verwenden Sie keinen möglicherweise baumelnden Zeiger.
2. Übergeben Sie keinen möglicherweise baumelnden Zeiger an eine andere Funktion.
3. Geben Sie keinen möglicherweise baumelnden Zeiger von einer Funktion zurück.

Weitere Informationen zum Verlauf und zu den Zielen des Profils finden Sie in Herb Sutters Blogbeitrag zu Version 1.0 .

Was ist neu in Visual Studio 2019 Vorschau 2

In Vorschau 2 haben wir eine Vorschauversion des Lifetime Profile Checker ausgeliefert, die die veröffentlichte Version des Lifetime Profile implementiert. Dieser Checker ist Teil der C ++ Core Checker in Visual Studio.

• Unterstützung für Iteratoren, Zeichenfolgenansichten und Bereiche.
• Bessere Erkennung von benutzerdefinierten Eigentümer- und Zeigertypen, sodass benutzerdefinierte Typen, die sich wie Container, Eigentümerzeiger oder Nicht-Eigentümerzeiger verhalten, an der Analyse teilnehmen können.
• Typbezogene Standardregeln für Vor- und Nachbedingungen von Funktionsaufrufen tragen dazu bei, Fehlalarme zu reduzieren und die Genauigkeit zu verbessern.
• Bessere Unterstützung für Aggregattypen.
• Allgemeine Korrektheit und Leistungsverbesserungen.
• Einige einfache Nullptr-Analysen.

Aktivieren der Regeln für die Prüfung des Lebenszeitprofils

Die Prüferregeln sind standardmäßig nicht aktiviert. Wenn Sie die neuen Regeln ausprobieren möchten, müssen Sie den für Ihr Projekt ausgewählten Regelsatz für die Codeanalyse aktualisieren. Sie können entweder die "C ++ Core Check Lifetime Rules" auswählen, die nur die Lifetime Profile-Regeln aktivieren, oder Sie können Ihren vorhandenen Regelsatz ändern, um die Warnungen 26486 bis 26489 zu aktivieren.

Screenshot der Eigenschaftenseite der Codeanalyse, auf der der ausgewählte Regelsatz für C ++ Core Check Lifetime Rules angezeigt wird.

Warnungen werden in der Fehlerliste angezeigt, wenn die Codeanalyse ausgeführt wird (Analysieren> Codeanalyse ausführen) oder wenn Sie die Hintergrundcodeanalyse aktiviert haben, werden lebenslange Fehler im Editor mit grünen Schnörkeln angezeigt.

Screenshot mit einer Warnung zur Überprüfung des Lebenszeitprofils mit einem grünen Kringel im Quellcode.

Beispiele

Baumelnder Zeiger

Das einfachste Beispiel - mit einem baumelnden Zeiger - ist der beste Ausgangspunkt. Hier zeigt px auf x und dann verlässt x Bereich und lässt px baumeln. Wenn px verwendet wird, wird eine Warnung ausgegeben.

 void simple_test() { int* px; { int x = 0; px = &x; } *px = 1; // error, dangling pointer to 'x' } 

Baumelnder Ausgabezeiger

Das Zurückgeben von baumelnden Zeigern ist ebenfalls nicht zulässig. In diesem Fall wird angenommen, dass der Parameter ppx ein Ausgabeparameter ist. In diesem Fall wird auf x was am Ende der Funktion den Gültigkeitsbereich verlässt. Dies lässt *ppx baumeln.

 void out_parameter(int x, int** ppx) // *ppx points to 'x' which is invalid { *ppx = &x; } 

Baumelnde Schnuransicht

Die letzten beiden Beispiele waren offensichtlich, aber temporäre Instanzen können subtile Fehler verursachen. Können Sie den Fehler im folgenden Code finden?

 std::string get_string(); void dangling_string_view() { std::string_view sv = get_string(); auto c = sv.at(0); } 

In diesem Fall wird die Zeichenfolgenansicht sv mit der temporären Zeichenfolgeninstanz erstellt, die von get_string() . Die temporäre Zeichenfolge wird dann zerstört, sodass die Zeichenfolgenansicht auf ein ungültiges Objekt verweist.

Dangling Iterator

Ein weiteres schwer zu erkennendes Problem für die Lebensdauer tritt auf, wenn ein ungültiger Iterator in einem Container verwendet wird. Im folgenden Fall kann der Aufruf von push_back dazu führen, dass der Vektor seinen zugrunde liegenden Speicher neu push_back wodurch der Iterator ungültig it .

 void dangling_iterator() { std::vector<int> v = { 1, 2, 3 }; auto it = v.begin(); *it = 0; // ok, iterator is valid v.push_back(4); *it = 0; // error, using an invalid iterator } 

Bei diesem Beispiel ist zu beachten, dass es für 'std :: vector :: push_back' keine spezielle Behandlung gibt. Dieses Verhalten entspricht nicht den Standardprofilregeln. Eine Regel klassifiziert Container als "Eigentümer". Wenn dann eine nicht konstante Methode für den Eigentümer aufgerufen wird, wird angenommen, dass der eigene Speicher ungültig ist, und Iteratoren, die auf den eigenen Speicher verweisen, werden ebenfalls als ungültig betrachtet.

Geänderter Besitzer

Das Profil ist in seiner Anleitung vorschreibend. Es wird erwartet, dass der Code beim Definieren von Funktionsparametern das Typsystem idiomatisch verwendet. In diesem nächsten Beispiel wird std::unique_ptr , ein 'Owner'-Typ, als nicht konstante Referenz an eine andere Funktion übergeben. Gemäß den Regeln des Profils wird angenommen, dass Eigentümer, die als nicht konstante Referenz übergeben werden, vom Angerufenen geändert werden.

 void use_unique_ptr(std::unique_ptr<int>& upRef); void assumes_modification() { auto unique = std::make_unique<int>(0); // Line A auto ptr = unique.get(); *ptr = 10; // ok, ptr is valid use_unique_ptr(unique); *ptr = 10; // error, dangling pointer to the memory held by 'unique' at Line A } 

In diesem Beispiel erhalten wir den ptr auf den Speicher von unique . Dann wird unique als nicht use_unique_ptr Referenz an die Funktion use_unique_ptr . Da dies eine nicht konstante Verwendung von unique bei der die Funktion alles tun kann, geht die Analyse davon aus, dass unique 'irgendwie ungültig ist (z. B. unique_ptr :: reset), was dazu führen würde, dass ptr baumelt.

Weitere Beispiele

Es gibt viele andere Fälle, die die Analyse erkennen kann. Probieren Sie es in Visual Studio mit Ihrem eigenen Code aus und sehen Sie, was Sie finden. Weitere Beispiele finden Sie auch in Herbs Blog. Wenn Sie neugierig sind, lesen Sie das Lifetime Profile-Dokument.

Bekannte Probleme

Die aktuelle Implementierung unterstützt die Analyse nicht vollständig, wie im Lifetime Profile-Dokument beschrieben. Hier sind die allgemeinen Kategorien aufgeführt, die in dieser Version nicht implementiert sind.

• Anmerkungen - In diesem [[gsl::lifetime-const]] Anmerkungen (dh [[gsl::lifetime-const]] ) vorgestellt, die nicht unterstützt werden. Praktisch bedeutet dies, dass Sie nichts anderes tun können, als falsch positive Ergebnisse zu unterdrücken , wenn die Standardanalyseregeln für Ihren Code nicht funktionieren.
• Ausnahmen - Ausnahmebehandlungspfade, einschließlich des Inhalts von catch Blöcken, werden derzeit nicht analysiert.
• Standardregeln für STL-Typen - Anstelle einer Annotation mit lifetime-const Dokument empfohlen, die seltenen STL-Containerelementfunktionen, bei denen die Standardeinstellungen überschrieben werden sollen, so zu behandeln, als wären sie mit Annotationen versehen. Zum Beispiel ist eine Überladung von std::vector::at nicht const weil sie eine Nicht-const-Referenz zurückgeben kann - wir wissen jedoch, dass der Aufruf lifetime-const weil sie den Speicher des Vektors nicht ungültig macht. Wir haben die Arbeit für diese implizite Annotation aller STL-Containertypen noch nicht abgeschlossen.
• Lambda-Erfassungen - Wenn eine Stapelvariable als Referenz in einem Lambda erfasst wird, erkennen wir derzeit nicht, ob das Lambda den Bereich der erfassten Variablen verlässt.
  
  

   auto lambda_test() { int x; auto captures_x = [&x] { return x; }; return captures_x; // returns a dangling reference to 'x' } 

Einpacken

Probieren Sie den Lifetime Profile Checker in Visual Studio 2019 Preview 2 aus. Wir hoffen, dass er Ihnen dabei hilft, lebenslange Probleme in Ihren Projekten zu identifizieren. Wenn Sie falsch positive oder falsch negative Ergebnisse finden, melden Sie diese bitte, damit wir die für Sie wichtigen Szenarien priorisieren können. Wenn Sie Vorschläge oder Probleme mit dieser Prüfung oder einer Visual Studio-Funktion haben, melden Sie entweder ein Problem oder posten Sie es in der Entwickler-Community und lassen Sie es uns wissen. Wir sind auch auf Twitter unter @VisualC .