Frage zu new/delete (C++)

[Sabi (herr_flitzpiep)]

Hallo,

ich kann die Warnung beim Code unten (gegen Ende, bei "delete[] cells") 
nicht nachvollziehen. Der einzige Grund für eine fehlende 
Initialisierung von "cells" wäre doch eine Exception beim ersten new. 
Dann würde aber der Code im catch-Block gar nicht erreicht. Oder sehe 
ich das falsch?

int** alloc_cells(size_t rows, size_t columns)
{
  int** cells { new int* [rows] };
  
  size_t row_idx {};
  try {
    while (row_idx < rows) {
      cells[row_idx] = new int[columns];
      ++row_idx;
    }
  }
  catch (const std::bad_alloc&) {
    for (size_t remove_idx {}; remove_idx < row_idx; ++remove_idx) {
      delete[] cells[remove_idx];
    }
  
    delete[] cells; // Warning C6001: Using uninitialized memory 'cells'
    cells = nullptr;

    throw;
  }

  return cells;
}

Hinweis: Das ist eigentlich eine "Hilfs-Klassenfunktion" für eine kleine 
Übung aus einem Buch, bei der es um manuelles Speichermanagement geht; 
dass dies bei
"richtigem" C++-Code nicht so gemacht werden sollte, ist mir klar (und 
wird auch explizit erwähnt). Ich habe als Typ oben der Einfachheit 
halber statt "SpreadsheetCell" int verwendet.

// Vorgegeben
class Spreadsheet
{
  ...
  SpreadsheetCell** m_cells { nullptr };
};

[Oliver S. (oliverso)]

Die Warnung liefert gerne mal false positives.

Oliver

[Yalu X. (yalu) (Moderator)]

Vergiss die Warnung. Sie ist nicht nachvollziehbar, da cell ja definitiv
in Zeile 3 initialisiert wird. Das scheint eine blöde Eigenart des
MS-C++-Compilers zu sein, denn andere Compiler (g++ und clang++) liefern
keine Warnung.

[Rolf M. (rmagnus)]

Yalu X. schrieb:
> denn andere Compiler (g++ und clang++) liefern keine Warnung.

Die warnen nur, wenn man die Initialisierung von cells entfernt. Da 
scheint also dieser Compiler einen Bug in der Kontrollfluss-Analyse zu 
haben.

[Oliver S. (oliverso)]

„Die anderen“ sind bei der Warnung auch nicht ganz fehlerfrei. Das 
verhindern von false positives scheint nicht so trivial zu sein.

Oliver

[Yalu X. (yalu) (Moderator)]

Oliver S. schrieb:
> „Die anderen“ sind bei der Warnung auch nicht ganz fehlerfrei. Das
> verhindern von false positives scheint nicht so trivial zu sein.

Ob eine Variable initialisiert ist oder nicht, ist nicht allgemein
entscheidbar. g++ und clang gehen mit diesem Problem auf verschiedene
Weise um:

g++ sagt "‘<variable>' may be used uninitialized", wenn er trotz
durchgeführter Kontrolflussanalyse sich nicht absolut sicher ist, dass
die Variable initialisiert ist. Das ist insbesondere dann der Fall, wenn
die Initialisierung der Variable fehlt und eine Zuweisung nur bedingt
erfolgt. Er verwendet das Wörtchen "may", um auf seine Unsicherheit
hinzuweisen.

clang++ sagt "'<variable>' is uninitialized when used here", wenn er
sich absolut sicher ist, dass die Variable uninitialisiert ist. Das ist
immer dann der Fall, wenn die Initialisierung der Variable fehlt und
keine Zuweisung (auch keine bedingte) vor der ersten Lesezugriff
erfolgt. Dadurch kann es allerdings passieren, dass bei einer
tatsächlich uninitialisierten Variable die Warnung ausbleibt.

Da er MS-Compiler mitunter auch dann warnt, wenn selbst ohne großartige
Kontrolflussanalyse offensichtlich ist, dass die Variable initialisiert
ist, wäre er gut beraten, seine Warnung "Using uninitialized memory
'<variable>' etwas weniger strikt (bspw. mit einem "Possibly" davor) zu
formulieren ;-)

[Sabi (herr_flitzpiep)]

Danke für die Infos!
Wenn das bei einem "richtigen" Projekt auftritt, könnte man - wenn 
sicher ist, dass dort kein Problem vorhanden ist - vielleicht so etwas 
machen(?)

#if defined(_MSC_VER)
#define MSVC_DISABLE_WARNING_UNINITIALIZED_MEMORY __pragma(warning(push)) \
__pragma(warning(disable: 6001))
#define MSVC_RESTORE_WARNINGS __pragma(warning(pop))
#else
#define MSVC_DISABLE_WARNING_UNINITIALIZED_MEMORY
#define MSVC_RESTORE_WARNINGS
#endif

...
MSVC_DISABLE_WARNING_UNINITIALIZED_MEMORY
  ...
MSVC_RESTORE_WARNINGS

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Sabi schrieb:

> ich kann die Warnung beim Code unten (gegen Ende, bei "delete[] cells")
> nicht nachvollziehen.

cells hat einen definierten Wert, der Speicherbereich, auf den cells 
zeigt allerdings nicht. Die definierten Werte bekommt, cells erst in 
Zeile 8. Wenn in Zeile 8 eine Ausnahme auftritt, dann können noch einige 
Elemente von *cells nicht initialisiert sein. In der Ausnahmebehandlung 
wird dann delete auf nicht initialisierten Werten ausgeführt.

Ein Grund mehr, warum jedes Objekt maximal eine dynamische Resource 
verwalten sollte. Wenn Du cells durch einen std::vector ersetzt, ist das 
Problem schon gelöst.

[Niklas G. (erlkoenig)]

Torsten R. schrieb:
> dann können noch einige
> Elemente von *cells nicht initialisiert sein. In der Ausnahmebehandlung
> wird dann delete auf nicht initialisierten Werten ausgeführt.

Nein, die for-Schleife durchläuft nur die zuvor korrekt angelegten 
Elemente.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Niklas G. schrieb:

> Nein, die for-Schleife durchläuft nur die zuvor korrekt angelegten
> Elemente.

Stimmt.