3. String einen substring über mehrere Zeilen

String einen substring über mehrere Zeilen

  • M

    Noch ein paar allgemeine Fragen:

    @ Helppls1234: Wie fix ist denn Dein Dateiformat? Das Ini-Format, was ich so kenne, braucht eigentlich keine schließenden Tags. Es enthält "Sections" (das in den eckigen Klammern) und dahinter Key-Value-Paare, bis zur nächsten Section oder Dateiende. Deine Datei wäre dann z.B.:

    `[Schurke]

    Str=12

    Dex=17

    Int=4

    [Krieger]

    Str=18

    Dex=10

    Int=2`

    Das würde den Parser etwas vereinfachen...

    @ SeppJ: Warum gibst Du bei den get -Methoden nicht einfach den Wert zurück? Schon klar, Template-Typ muss in die Signatur, aber irgendwie fühlt es sich komisch an, bei einem get() den Wert als Referenz zu übergeben und die Möglichkeit eines Rückgabewertes durch void zu verschenken.

    Bei einer Ini-Datei würde ich aus dem Bauch raus die Values entweder fix als string zurückgeben (und die Interpretation nach int oder double später; der Parser soll ja den Typ der einzelnen Values gar nicht kennen müssen), oder gerne die Templates so wie sie sind und dann speziell einen anderen Typ anfordern.

    Also statt:

    int a;
sip.get_verbose(std::cout, "Krieger", "Str", a);

    etwa so:

    int a = sip.get_verbose<int>(std::cout, "Krieger", "Str");

    @Sone: Warum nicht einfach ein vector aus shared_ptr ? Bei Containern aus puren Pointern (und den dazugehörigen selbstgeschriebenen Lösch-Schleifen) krieg ich inzwischen Gänsehaut). Also statt

    std::vector<Node*> child_nodes; // Darf *nicht* verändert werden - Inhalt wird gelöscht

    ~Node()
    {
        std::for_each( std::begin(child_nodes), std::end(child_nodes), static_cast<void(*)(void*)>(operator delete) );
    }

    std::vector<std::shared_ptr<Node>> child_nodes; // Darf *nicht* verändert werden - Inhalt wird gelöscht
    0

  • @SeppJ

    isoiec14882 19.1.1 - 1 schrieb:

    The class logic_error defines the type of objects thrown as exceptions to report errors presumably detectable before the program executes, such as violations of logical preconditions or class invariants.

    Für mich bedeutet das: man muss ein Programm so schreiben können dass es keine logic_error wirft.
    Im Falle von fehlerhaften Input-Files würde das bedeuten dass man das File erstmal selbst verifizieren müsste bevor man es dem Parser füttern darf.
    Was sinnlos ist.

    => Der Parser sollte keine logic_error werfen.

    Ich kenne übrigens auch keinen Programmierer der das anders interpretiert.

    0
  • Mod

    minastaros schrieb:

    @ SeppJ: Warum gibst Du bei den get -Methoden nicht einfach den Wert zurück? Schon klar, Template-Typ muss in die Signatur, aber irgendwie fühlt es sich komisch an, bei einem get() den Wert als Referenz zu übergeben und die Möglichkeit eines Rückgabewertes durch void zu verschenken.

    Damit man den Typ nicht angeben braucht, sondern die automatische Templateparametererkennung nutzen kann.

    0
  • ?

    SeppJ schrieb:

    minastaros schrieb:

    @ SeppJ: Warum gibst Du bei den get -Methoden nicht einfach den Wert zurück? Schon klar, Template-Typ muss in die Signatur, aber irgendwie fühlt es sich komisch an, bei einem get() den Wert als Referenz zu übergeben und die Möglichkeit eines Rückgabewertes durch void zu verschenken.

    Damit man den Typ nicht angeben braucht, sondern die automatische Templateparametererkennung nutzen kann.

    Einerseits das, andererseits funktioniert das auch im pathologischen Fall, wenn der Typ keinen Default-Konstruktor hat. Dieses get() ist richtig.

    Was ich allerdings nicht ok finde, ist die Schwesterfunktion

    template<typename T> void get(std::string const& category, std::string const& name,
                                T &entry, const T& default_value) const
  {
    try
      {
        get(category, name, entry);
      }
    catch (std::logic_error)
      {
        entry = default_value;
      }
  }

    Manche (mich eingeschlossen) würden diese Nutzung von Exceptions als "premature Pessimization" beschreiben.

    Dazu kommt:
    - "Throw by value, catch by reference" -- hier nicht schlimm, aber grundsätzlich schlechter Stil
    - Bei normalen Ini-Dateien gilt: Fehler ausgeben bei fehlerhaftem Wert, Defaultwert bei fehlender Angabe, sonst der angegebene Wert. Für dieses get() wird "kein Wert" und "falscher Wert" gleich behandelt. Womöglich wieder eine bewusste Entscheidung!?

    hustbaer schrieb:

    => Der Parser sollte keine logic_error werfen.

    Schön, dass ich nicht der einzige bin, der das so sieht.

    0
  • Mod

    kritticker schrieb:

    Womöglich wieder eine bewusste Entscheidung!?

    Nein, in allen drei Fällen Faulheit. Eine Defaultwertfunktion war lauf Aufgabenstellung verlangt. Durch Mitnutzung der normalen get-Funktion, konnte ich mir so die Codewiederholung sparen. Das get ist nicht Kernteil dessen gewesen, was ich vorführen wollte.

    0
  • S

    Und der Code-Blah ist einfach überwältigend.

    Supi! Sollte es auch sein. Ein möchtegern-Perfektionist wie ich...

    Hier der optimierte Code.
    http://ideone.com/lNJGDO

    0
  • Mod

    Wow, mein Rechner setzt erst einmal eine Sekunde aus, wenn er den Tab mit dem Quelltext lädt 😮 .

    0
  • S

    SeppJ schrieb:

    Wow, mein Rechner setzt erst einmal eine Sekunde aus, wenn er den Tab mit dem Quelltext lädt 😮 .

    Langsamer Rechner, nicht wahr?

    Hier die Geschwindigkeiten, die ich gemessen habe:

    Kritticker: 3547000 
Sone:       1210000
SeppJ:      710000

    Verdammt, da hat der SeppJ aber Schwein. Nur weil ich so viel drumherum habe.

    0
  • Mod

    Das ist kein Glück. Was erwartet ihr denn von solch fetten Codes? Gerade die Regex von Kritticker sind Overkill³. Bei dir kann man wenigstens sagen, dass dein Code mehr kann.

    0
  • ?

    Ich glaube es ist schlechter Stil die Exceptions einfach nur mit einem englischen Text zu beschreiben. Was ist, wenn das Programm mal im Ausland läuft. 🙄

    0
  • K

    Nun, wenn eine Bibliothek mir Exceptions entgegenwirft, nur weil sie mit ein paar falschen Eintraegen konfrontiert wird, dann wuerde ich die Bibliothek wechseln.

    Supi! Sollte es auch sein. Ein möchtegern-Perfektionist wie ich...

    Code sollte einfach sein.

    0
  • ?

    Ich hätte einfach ne XML & nen einfachen XML Parser wie irrXML genommen...

    0
  • K

    Es ist grundsaetzlich falsch, die Worte 'einfach' und XML in einem Satz zu sagen. 🙂

    0
  • ?

    knivil schrieb:

    Es ist grundsaetzlich falsch, die Worte 'einfach' und XML in einem Satz zu sagen. 🙂

    Wieso? Man brauch nicht für jeden Furz nen Xercxes Parser und andere Späße mit tausendfacher DOM Validierung und ähnlichem Kram.
    Manchmal ist weniger einfach mehr.
    irrXML ist schnell, einfach. Kann dafür wenig.
    Aber solange man nur lesen will und nicht validieren, sehe ich daran nichts falsches.

    0
  • K

    Habe ich von irrXML als Bibliothek gesprochen? Nein!

    PS: Habe gerade irrXML-Api ueberflogen. Sorry, im Vergleich zu anderen XML-Gedoens ist es vielleicht leichtgewichtig, aber im Vergleich zu ini-Parser oder JSON-Parser trotzdem Schwergewicht. Es ist auch schwer zu sagen, wie fehlertolerant irrXML ist. Bei ini-Files sehr einfach zu bewerkstelligen, naja, ausser Sones Implementierung, die mit Exceptions um sich wirft.

    0
  • ?

    Man kann natürlich auch JSON nehmen. Mir wayne. Mir gings nur darum, dass man lieber auf bewährte Dinge setzen sollte als sich das Leben unnötig schwer zu machen.

    0

  • was anderes schrieb:

    Ich glaube es ist schlechter Stil die Exceptions einfach nur mit einem englischen Text zu beschreiben. Was ist, wenn das Programm mal im Ausland läuft. 🙄

    Exceptions zu übersetzen ist natürlich die ganz tolle Idee. 🙄

    Darf ich fragen was du mit deinem Beitrag sagen willst?

    0
  • ?

    hustbaer schrieb:

    was anderes schrieb:

    Ich glaube es ist schlechter Stil die Exceptions einfach nur mit einem englischen Text zu beschreiben. Was ist, wenn das Programm mal im Ausland läuft. 🙄

    Exceptions zu übersetzen ist natürlich die ganz tolle Idee. 🙄

    Darf ich fragen was du mit deinem Beitrag sagen willst?

    Ich wollte damit einfach nur sagen das der Exception-Text im UI-Layer zusammengebaut werden sollte. Die Exception-Klasse sollte alle Informationen dazu beinhalten, aber nicht den Text selbst. 😉

    0

  • @was anderes
    Und ich bin der Meinung dass das für viele Applikationen Overkill ist.

    Und selbst dort wo es kein Overkill ist, will ich in der Exception selbst eine (verständliche, englische) Error-Message haben die bei what() zurückkommt. Und sei's nur zum Debuggen und/oder Loggen.

    Was ich bei der Sache allerdings schade finde, ist, dass die Standard-Library hier nicht mehr vorgibt. Also z.B. ne Möglichkeit einen Error-Code (z.B. in String-Form). Oder gleich die Möglichkeit in der Exception ein Objekt abzulegen das von irgend einer Basisklasse ("error_info") abgeleitet ist. Dort wäre dann auch schön Platz um diverse Zusatzinformationen ala Filename, System Error-Code, Username etc. abzulegen.

    Exception-Chaining wäre auch sehr hilfreich.

    Nagut, darum geht's ja hier nicht. Also [/OT]

    0
  • K

    Warum sollte man einer Exception mehr Information mitgeben als einen String fuer eine anstaendige Fehlermeldung. Nun man koennte den Fehlerfall ausgleichen und das Parsen an einem sicheren Punkt fortfuehren. Da finde ich aber Fehlerbearbeitungsfunktionen besser, die beim Start des Parsens der Funktion einfach mitgegeben werden. Exceptions halte ich fuer ungeeignet.

    0
Anmelden zum Antworten