Ein bisschen verwirrt über den Geltungsbereich und wie verschachtelte Strukturen für den Verzeichnisbaum erstellt werden

Question

Ich versuche, eine Verzeichnisbaum-Benutzeroberfläche einer unbekannten Menge von verschachtelten Ordnern anzuzeigen, die aus einer flachen Datei gelesen wird. Meine Idee war es, eine Struktur zu verwenden, die für Kinder und Eltern, wie so zeigen könnte:

struct audioSelectTreeItem { 
    FString folderName; 
    FString folderPath; 
    struct audioSelectTreeItem* folderParentItem; 
    TArray<struct audioSelectTreeItem*> childFolderItems; 
}; 

Wenn ich lese die Datei der gespeicherten Verzeichnisse speichere ich alle Unterordner in childFolderItems und die Eltern in folderParentItem. Auf diese Weise, wenn jemand einen Ordner hochgehen möchte, schaue ich auf folderParentItem und lese dann seine Unterordner mit childFolderItems aus.

Das Problem, auf das ich stoße, ist, wie man das speichert. Ich habe eine Funktion erstellt, die Ordner und untergeordnete Elemente durchläuft und alle diese Strukturen erstellen und speichern kann. Ich denke jedoch, das Problem ist, wenn ich eine Struktur in einer Schleife erstellen, dann speichern Sie einen Zeiger auf es in der vorherigen Struktur (Kinder Ordner) Ich kann nicht darauf zugreifen, von irgendwo sonst im Programm.

Gibt es eine Möglichkeit, diese permanenter zu erstellen, und wie würde ich darüber hinausgehen, wenn Sie fertig sind?

Bearbeiten: schrieb, als ob ich Live-Verzeichnisse lesen. War eine Textdatei mit Verzeichnisinformationen, die ich in eine Baumschnittstelle einfügen muss.

Update: Hier ist ein kleines Beispiel dafür, was die Schleife tut:

void AMyPlayerController::showAudioPicks() { 
for (int counter = startCount; counter < fileStringArray.Num(); counter++) { //startcount 3 

     audioSelectTreeItem newTreeItem; 
     newTreeItem.folderPath = fileStringArray[counter]; 
     mainListTree.childFolderItems.Add(&newTreeItem); 

...

Also mein Problem liegt das diese neue audioSelectTreeItem mit dem Erstellen von in structs hinzuzufügen verschachtelt, aber sie halten zugänglich anderswo im Programm.

Answer 1

Was Sie hier tun, ist ein Zeiger auf einen Stapel Variable zu schaffen, die für die Schleife und zerstört auf jeder Schleife die scoped ist:

audioSelectTreeItem newTreeItem; 
newTreeItem.folderPath = fileStringArray[counter]; 
mainListTree.childFolderItems.Add(&newTreeItem); 

Wenn Sie ein Objekt (oder Struktur) auf der zu erstellenden anstelle des Stapels Haufen, haben Sie new verwenden:

audioSelectTreeItem *newTreeItem = new audioSelectTreeItem; 
newTreeItem->folderPath = fileStringArray[counter]; 
mainListTree.childFolderItems.Add(newTreeItem); 

Aber wenn Sie dies tun, haben Sie das Objekt, um sicherzustellen, mit delete befreit. Typischerweise wird dies in dem Destruktor der audioSelectTreeItem Klasse (oder Struktur) durchgeführt:

class audioSelectTreeItem { 
public: 
    ~audioSelectTreeItem() 
    { 
     for (int i = 0; i < childFolderItems.Num(); i++) 
      delete childFolderItems[i]; 
    } 

    FString folderName; 
    FString folderPath; 
    class audioSelectTreeItem* folderParentItem; 
    TArray<class audioSelectTreeItem*> childFolderItems; 
}; 

Der Elternteil ist der Eigentümer seiner Kinder, so hat es keinen Sinn folderParentItem in löschen. Sobald Sie die Wurzel löschen, löscht der Destruktor alle seine Kinder und so weiter.

Im aktuellen C++ gibt es sicherere Lösungen für solche Bäume. Zum Beispiel könnten Sie verwaltete Zeiger anstelle von einfachen Zeigern verwenden. Dadurch entsteht ein Bit eines Overhead wegen Referenzzählung, aber Sie haben nie selbst den Haufen zu befreien:

#include <memory> 

class audioSelectTreeItem 
{ 
public: 
    FString folderName; 
    FString folderPath; 
    std::weak_ptr<audioSelectTreeItem> folderParentItem; 
    TArray<std::shared_ptr<audioSelectTreeItem>> childFolderItems; 
}; 

Sie keine shared_ptr für die folderParentItem Referenz verwenden. Dies würde zu einer zyklischen Abhängigkeit führen (Elternreferenzen Kinder- und Kinderreferenzen Eltern, so dass keine von ihnen gelöscht werden kann)

Und eine persönliche Meinung: Typennamen sollten mit einem Großbuchstaben beginnen.