Verzeichnissuche

[Kerli]

Achja, Verzeichnisssuche lässt sich wohl kaum völlig plattformunabhängig schreiben. Lösen wir das über Präprozessorerschalter oder soll der Code dann je nach plattform von C-Make erzeugt werden?

Da ist Kerli gefragt, ob CMake da Möglichkeiten anbietet.

Ansonsten stelle ich mir directoryindex.h und directoryindex/windows.cpp und directoryindex/posix.cpp vor, wobei CMake sich für das richtige entscheiden muss, bzw. in directoryindex.cpp ein Präprozessorschalter die jeweiligen Unterschiede included.

Ich würde eine plattformunabhängige Headerdatei schreiben und dann für jede unterstützte Plattform einen eigenen Ordner mit den Implementation erstellen. CMake kann man dann sagen abhängig von der Plattform die Dateien aus den entsprechenden Ordnern zu kompilieren und danach auch zu linken. zb:

Code: Alles auswählen

IF(APPLE)
  add_subdirectory(apple)
ELSEIF(WIN32)
  add_subdirectory(windows)
ELSE()
  add_subdirectory(linux)
ENDIF()

Eine andere Möglichkeit wenn Bibliotheken zwar auf mehreren Plattformen verfügbar sind aber nicht allen, wäre zu überprüfen ob bestimmte Headerfiles/Bibliotheken (mit FindPackage) vorhanden sind, und abhängig davon die entsprechende Implementation zu wählen.

[Bebu]

So hier ein erster Entwurf für eine Klasse, die eine Datei repräsentiert. Ich stelle sie mal hier rein, weil ich bestimmt noch einige große Änderungen vornehmen muss. Sagt mir einfach mal eure Meinung dazu:

Code: Alles auswählen

class file
{
    std::string name;
    std::string path;
    double size;
    hashobject hash;

    public:
     file(std::string name_c,
          std::string path_c,
          double size_c
         ) :
            name(name_c),
            path(path_c),
            size(size_c)
            {
                switch (check_database(name,path,size))
                {
                    case SOMETHING_CHANGED : hash.create_hash(path);
                                             update_database(name,path,size,hash);
                                             break;

                    case NOT_EXISTING      : hash.create_hash(path);
                                             update_database(name,path,size,hash); 
                                             break;
                }
            };

    ~file();

    std::string get_name()
    {
        return name;
    }
    std::string get_path()
    {
        return path;
    }
    double get_size()
    {
        return size;
    }
};

[cloidnerux]

@Bebu:
Warum die Dateigröße als Double?
Du hast doch keine Halben Bytes und die Prüfung von Fließkommazahlen dauert länger.
Auch könnte man sich darüber streiten, den Eintrag in die Datenbank der dem File-Handle zu übertragen, weil wir so schwerer Kontrolle darüber erhalten, was die Datei speichert, nicht, dass wir die gleiche Datei mehrfach eintragen-

Hier eine Ähnliche Implementation, sie ist nur als Beispiel zu betrachten
Ich habe den Namen der Datei nicht Explizit angegeben, er sollte im Pfad sein.
Die Dateigröße habe ich in einem unsigned long long gespeichert.
Die Klasse Hash repräsentiert einen Hash von einem Feld von Daten.
(Die Implemnetationen spare ich mir an dieser Stelle, da ist etwas zu viel Code drinn.)

Code: Alles auswählen

#ifndef FILEINFO_H_
#define FILEINFO_H_

#include "Hash.h"
#include <string>
#include <fstream>

using namespace std;

class FileInfo
{
private:
	Hash* fileHash;
	string path;
	uint64__ size;
	bool error;
public:
	/// <summary>
	/// Standardkonstruktor
	/// </summary>
	FileInfo();
	/// <summary>
	/// Initilaisiert das Objekt und Lädt die Informationen der Datei unter pathToFile
	/// </summary>
	FileInfo(string pathToFile);
	/// <summary>
	/// Gibt die Dateinformationen aus.
	/// </summary>
	void DisplayInfo();
};

[Bebu]

Warum double? Nenn es einen Denkfehler von mir

Wenn ich nochmal darüber nachdenke, gefällt mir eigentlich diese Idee noch besser: Ich lasse alle Dateien durchlaufen und übergebe dir am Schluss z. B. einen Vector mit allen Dateiobjekten. Wäre für mich einfacher. Was meint ihr? Zu Speicheraufwändig?

[cloidnerux]

Zu Speicheraufwändig?

Nein, ich könnte den Vector entweder weiterverwenden oder nach gebracuh Löschen

Was meint ihr?

Finde ich gut, dann haben wir eine höhere Modularität, was fehler schneller eingrenzt und wir können unsere Klassen unabhängig voneinander auf Basis einer Schnittstelle entwickeln.

[nufan]

Was spricht gegen eine rekursive Lösung bei der alle Unterverzeichnisse und Dateien in jeweils einer eigenen Liste gespeichert werden? Vorausschauend würde das die grafische Darstellung enorm erleichtern. Dieser Code setzt zwar stark auf Qt, das Grundprinzip sollte aber erkennbar sein.

[Bebu]

Was spricht gegen eine rekursive Lösung bei der alle Unterverzeichnisse und Dateien in jeweils einer eigenen Liste gespeichert werden? Vorausschauend würde das die grafische Darstellung enorm erleichtern. Dieser Code setzt zwar stark auf Qt, das Grundprinzip sollte aber erkennbar sein.

Dagegen spricht, das ich in meinem Modul, alle Verzeichnisse durchlaufe und sämtliche Informationen über einzelne Dateien sammle und als Objekt repräsentiere. Ein Fileobjekt enthält dann also folgenden Informationen: absoluter Pfad zur Datei, Dateiname, Dateigröße, Erstellungsdatum bzw. Änderungsdatum. Gefällt mir als Objekt einfach besser. Abgesehen davon, bekommst du am Ende eine Liste, nur besteht die aus Datenobjekten.

Nein, ich könnte den Vector entweder weiterverwenden oder nach gebracuh Löschen

Dazu habe ich einen Vorschlag: Diese Klasse bildet den kleinsten gemeinsamen Nenner. Ich sehe z. B. eine Objekteigenschaft vor, in der der Hashwert abgelegt wird und die Datenhaltung alle relevanten Daten abrufen und den Verarbeitungstatus festlegen kann z. B. existiert schon, nicht hashen, Datei verändert neu hashen, Datei existiert nicht, hashen und dann in Datenbank eintragen. Die Objektliste könnte dann von allen anderen Modulen weiterverarbeitet werden, und die Objekte lassen sich je nach Status dann auf unterschiedliche Container umverteilen und in die richtigen Module weiterleiten.

[Bebu]

Sorry Doppelpost, konnte meinen letzten Beitrag nicht mehr editieren.

Hier mein Vorschlag von oben in Code umgesetzt:

Code: Alles auswählen

enum state
{
    OK=0,
    ERROR,


    PATH_CHANGED,
    SIZE_CHANGED,
    NAME_CHANGED,
    DATE1_CHANGED,
    DATE2_CHANGED,
    GO_HASH,
    NOTHING_TO_DO
};

class file
{
    std::string name;
    std::string path;
    unsigned long long size;
    std::string date_created; //Dieser Datentyp kann sich noch ändern!
    std::string date_changed; //Dieser Datentyṕ kann sich noch ändern!

    std::string hash; //Was eignet sich für den Hashwert am Besten?

    short status;

    public:
     file(std::string name_c,
          std::string path_c,
          unsigned long long size_c,
          std::string date_created_c,
          std::string date_changed_c
         ) :
            name(name_c),
            path(path_c),
            size(size_c),
            date_created(date_created_c),
            date_changed(date_changed_c)
            {
            };

    ~file();

    std::string get_name()
    {
        return name;
    }

    std::string get_path()
    {
        return path;
    }

    unsigned long long get_size()
    {
        return size;
    }

    std::string get_date_created()
    {
        return date_created;
    }

    std::string get_date_changed()
    {
        return date_changed;
    }


    short set_hash(const std::string &hash_value)
    {
        hash = hash_value;
        return OK;
    }

    std::string get_hash()
    {
        return hash;
    }


    short set_status(const short &status_value)
    {
        status = status_value;
        return OK;
    }

    short get_status()
    {
        return status;
    }

};

Das wäre mein Vorschlag für das Interface. Unter welchem Punkt sollte ich das im Wiki eintragen Xin?

[Xin]

Das wäre mein Vorschlag für das Interface. Unter welchem Punkt sollte ich das im Wiki eintragen Xin?

project:dedupe:design:dir:start und einen Link in project:dedupe:design setzen, bitte.

[cloidnerux]

std::string hash; //Was eignet sich für den Hashwert am Besten?

Ein interger mit 32/64/128-Bit Breite.