3. Einlesen eines Files und davor dessen Zeilenanzahl bestimmen

Einlesen eines Files und davor dessen Zeilenanzahl bestimmen

  • W

    Schlangenmensch schrieb:

    Ich würde die Variablen immer erst da deklarieren wo ich sie brauche. Also im inneren der Schleife. Das macht den Code meiner Meinung nach besser zu lesen.

    Das würde ich gerne unterstützen! Vor allem fallen in diesem Fall dann auch die lästigen .clear() -Aufrufe weg.

    Wenn du optimieren willst, kannst du das getline + stringstream-Erzeugung vermeiden und die Zahlen direkt aus dem Dateistream lesen. Dann muss man nur aufpassen, selbst Whitespace zu überspringen und im Falle eines Umbruchs die Behandlung des Umbruchs selbst machen. Werner Salomon hätte dafür bestimmt auch eine Lösung in "schön" 😉

    0
  • S

    das war meine frage vor einigen Tagen in einem verwandten Thread als ich fragte ob man Objecte lieber in Loops immer wieder aufs Neue deklariert oder einmal vor der Loop und dafür dann wieder resettet.

    Da war der Tenor, dass man bei größeren Objekten lieber zweitere Lösung bevorzugt.

    Was wäre der Vorteil von nem eigenen Parser gegenüber nem stringstream?

    0
  • ?

    Sewing schrieb:

    Da war der Tenor, dass man bei größeren Objekten lieber zweitere Lösung bevorzugt.

    Nein, war er nicht!

    0
  • S

    hab das ganze jetzt modifiziert gemäß euren Anregungen

    std::string line{}; 
  for (auto const &filename : FileNames_) {
    if (filename.find("Image") != std::string::npos) continue;
    std::ifstream inputFile{filename};
    assert(inputFile.is_open() && !inputFile.fail());
    for (size_t i = 1; i <= 11; ++i) {  // ignore the first 11 lines for pcd
      inputFile.ignore(std::numeric_limits<std::streamsize>::max(), '\n');
    }
    while (getline(inputFile, line)) {
      if (line.empty()) continue;  // Ignore empty lines
      std::istringstream istream{line};
      pointClouds_[cloudName].emplace_back(
          std::istream_iterator<float>{istream},
          std::istream_iterator<float>{});
    }
  }
    0

  • Sewing schrieb:

    das war meine frage vor einigen Tagen in einem verwandten Thread als ich fragte ob man Objecte lieber in Loops immer wieder aufs Neue deklariert oder einmal vor der Loop und dafür dann wieder resettet.

    Da war der Tenor, dass man bei größeren Objekten lieber zweitere Lösung bevorzugt.

    Dann hast du meinen Kommentar falsch verstanden.

    Sewing schrieb:

    Was wäre der Vorteil von nem eigenen Parser gegenüber nem stringstream?

    Dass er viel schneller sein wird. Das kann schnell mal Faktor 10 oder 100 ausmachen.
    Was nicht heisst dass es sich immer auszahlt. Ob 0.1ms oder 10ms (komplette Laufzeit des Programms) ist vermutlich Wurst. 1 Sekunde statt 1 Minute
    ist vermutlich nicht Wurst.

    Ist aber vermutlich ne interessante Übung falls du es noch nie gemacht hast.

    0
  • S

    ich danke dir

    0
  • W

    Mir ist gerade noch was anderes aufgefallen:

    assert(inputFile.is_open() && !inputFile.fail());

    Ein Assert ist eigentlich etwas, das immer korrekt sein soll und ansonsten einen Programmierfehler zeigen soll und z.B. in Release-Builds wegfallen kann. Finde ich "kreativ", das für den Erfolg von Dateioperationen zu verwenden 😉

    Du hast auch im weiteren Programmverlauf nur ungenügend Fehlerchecking. Was ist, wenn irgendeine Zeile irgendwo einen Nicht-Float enthält? Das fällt gar nicht auf, dann fehlen einfach die restlichen Einträge der entsprechenden Zeile.

    0
  • S

    Danke für die Anregungen, aber das open soll doch immer korrekt sein...
    wie hättest dus gemacht? Mit ifs und exceptions?

    was das parsen angeht:

    Ich bin da immer unentschlossen: Man kann doch nicht jedwede Möglichkeit abfangen...

    0
  • S

    Was ist denn, wenn die Datei z.B. nicht exisitiert? Dann schlägt die Assertion fehl.
    Üblicherweise willst du dein Programm dann nicht direkt beenden, sondern dem Nutzer zum Beispiel eine Meldung ausgeben, dass die Datei nicht existiert und der User den korrekten Dateinamen eingeben oder auswählen soll.

    Exceptions sind dafür zum Beispiel eine Möglichkeit.

    Das gilt auch fürs Parsen. Wie sieht es denn aus, wenn ein Programm abstürzt, weil eine fehlerhafte Datei eingelesen wird. Auch hier muss eine entsprechende Fehlermeldung an den Nutzer ausgegeben werden. Wenn was unvorhersgehenes geparst wird, macht dein Programm nachher irgendwas anderes, was möglicherweise in der nachfolgenden Verarbeitung zu Problemen führt. Und dann kommt man nicht mehr so leicht darauf, dass da der Fehler ja auch beim parsen liegen könnte.

    Da du deinen vector irgendwas mit Point Cloud genannt hast, je nach Sensor kommen da um Beispiel NaN oder infinity vor, da hab ich selbst blöde Erfahrungen mit machen müssen.

    0
  • Mod

    Schlangenmensch schrieb:

    Was ist denn, wenn die Datei z.B. nicht exisitiert? Dann schlägt die Assertion fehl.
    Üblicherweise willst du dein Programm dann nicht direkt beenden, sondern dem Nutzer zum Beispiel eine Meldung ausgeben, dass die Datei nicht existiert und der User den korrekten Dateinamen eingeben oder auswählen soll.

    Interessanter ist doch die Frage, was passiert, wenn man im Release die Assertions ausschaltet. Hier wurde ein Codeprüfwerkzeug missbraucht, um Programmlogik umzusetzen.

    0
Anmelden zum Antworten