✔ Requläre Ausdrücke mal anders herum

[Enumerator]

Moin!

Ich habe nicht gesagt, dass die Liste nur aus Wörtern besteht - sonst würde ich mich ja einfach auf Whitespaces beschränken. Die Liste ist nicht einmal typisiert.

Im Prinzip exisitiert dieser Zusammenhang ja nur aus Bequemlichkeit - ich wollte, als ich das Format ersonnen habe, einfach verhindern, beim Speichern für jede Liste eine Neue Datei anzulegen.
Mein Algorithmus untersucht das Array vor der Auslagerung und prüft, welche Methode am sinnvollsten ist. Meist ist das die interne, da die Listen nur selten Referenzen auf komplexe Objekte enthalten.
Das funktioniert ja alles auch ganz prima, auch die Implementation des ganzen in Perl - ursprünglich ja nur für PHP gedacht - hat keine Probleme verursacht. Und in PHP glaubt man sowieso nicht an Performance...

Wie dem auch sei, der Server ist fertig geworden. Schade nur, das mein Format mit diesem Kloß am Bein wohl keine Zukunft haben wird. Dabei wären die Anwendungsgebiete noch lange nicht ausgeschöpft.

Gruß
Enum

 

[shutdown]

Warum verwendest du denn keine Kombination von Trennzeichen?
So gehe ich immer vor, wenn es um Bereiche geht, wo ich die Eingaben der Benutzer nicht vorhersagen kann.

Zum Beispiel könntest du als Trennzeichen verwenden:

<<<|||>>>
<->|||<->
|||---|||<>|||---|||

Und dass solche Kombinationen sonst noch mal in der Datei auftauchen, ist eher unwahrscheinlich

 

[Gumbo]

Ich habe nicht gesagt, dass die Liste nur aus Wörtern besteht - sonst würde ich mich ja einfach auf Whitespaces beschränken.

Ich meinte Wörter im Sinne der theoretischen Informatik und nicht „normale“ Wörter.


Die Verwendung von beliebigen Zeichenfolgen als Trennung ist nicht sinnvoll. Denn ähnlich dem Kerkhoffs-Prinzip sollte die Integrität des Formats nicht von der Geheimhaltung der Schlüsselzeichen abhängig sein. Zudem blähen deine Trennsequenzen die Daten unnötig auf.

 

[Enumerator]

Es spielt keine Rolle, wie der Trenn-'String' aussieht. Ausser, man ist meist selbst der Eingebende und möchte nicht soviel Tippen. ;-)
Die Implementation des Formates, vor allem die einlesende Routine kommt auch mit Sachen klar wie...

labc	aNyThInG24	guck ma wer da sprichtabc "guckuck"abc '>>x ala ödf aad s abcabcabc

Bei der eigenlichen Speicherung - also wenn ich die Struktur des generierten Objektes im binärformat auf Platte schreibe, geht die Information wie der Trennstring ausgesehen hat verloren. Es gibt auch keinen Grund, diesen mit zu speichern - zumal er ja nach der Manipulation des Objektes ungültig werden kann.
Das Problem entsteht erst, wenn ich - zu Diagnosezwecken oder eben bei der Portierung in andere Systeme - das ganze wieder in lesbare Dateien zurück verwandle.
Wie bereits gesagt, das Funktioniert schon alles. Die Implementierung kann quasi jedes x-Beliebige Objekt in Logs oder wasweisich schreiben. Nur DAUERT DAS ZU LANGE, weil ich aus Bequemlichkeit verhindern wollte für eine Liste wie die oben gleich eine zweite Datei anzulegen. Das lohnt sich einfach nicht!
Meine Funktion erlaubt zwar, via Argument das Abschalten des Versuchs Arrays intern zu speichern. Dann rennt das Modul wie ein Weltklassesprinter.
Nur leider sind die meisten Listen eben recht kurz und/oder enthalten keine komplexen Objekte. Wenn ich nun die Struktur im Schnellmodus ausgebe, habe ich ganz fix mal ein paar hundert Dateien mit nicht mal einem KB...

Gruß
Enum