bestimmtes Wort aus einem String auslesen

[Mavarik]

Zitat von KodeZwerg:

Zitat von himitsu:

PoSex

Du weißt schon was da steht?

Man könnte auch bei Pos() per Offset ans Ziel kommen.

Hast Du etwas gegen... Nein das führt hier in die falsche Richtung...

@himitsu

Klar, aber performant ist das mit der Stringliste nicht.

[KodeZwerg]

Zitat von himitsu:

Ohhh, seit wann hat denn das normale Pos ein optionales Offset?

Das ist eine Super Frage im allgemeinen.
Bei Pos() kenne ich es seit Ewigkeiten, aber wie findet man so etwas ganz genau raus wann welche funktion/methode eingeführt bzw um Parameter X erweitert wurde. Bei solchen Fragen stehe ich immer aufm Schlauch.

Sorry wegen der anderen Anspielung, ich fands lustig in dem Moment.

[himitsu]

Ja, du kannst halt entweder die Hilfen durchblättern (viele Versionen seit 2006 sind online),
oder man könnte den Quellcode der Installation vergleichen. (vielleicht hast'e ein Backupprogramm, was dir ein Diff bietet)

Ich hatte mal angefangen die Delphi-Installationen in ein lokales Git-Repo zu schieben, damit man sowas vergleichen/suchen kann, weil ich mich auch öfters mal sowas frage,
aber effektiv hab ich erst die TurboPascal bis Delphi 1 fertig .... und veröffentlichen kann ich das ab Delphi auch nicht.
Vielleicht könnte mal via GetIt, an die "bestätigten" Besitzer der jeweiligen Delphi-Editionen inkl. Vorgänger. (selbst prüfen wer es hat, will ich nicht)

Für eine vollständige Historie fehlt mir aber noch bissl was.
BLS Pascal (PolyPascal ist da, aber der Vorgänger nicht), Delphi EEP (kenn niemanden, der es hatte), Delphi 5 und Delphi 6.

Ist aber nur ein Hobbyrojektchen, was so seit 'nem Jahr läuft und wo ich selten was dran mach.


Bei den StringHelprn hatte ich paar mal geguckt,
aber hier nie ... es gab ja PosEx.

Zitat:

performant

Och, alles "hochoptimieren" tu ich nicht mehr.
Wenn es geht, dann mach ich lieber "einfach". (auch wenn es 'ne nanosekunde langsamer sein mag)

Und ja, per se nehme ich auch lieber Lösungen, welche ohne Extra-Speicheroperationen auskommen, also direkt suchen, anstatt umformatieren und dann ... aber machmal ist "einfach" eben einfacher.

[Mavarik]

OT:

Zitat von himitsu:

Och, alles "hochoptimieren" tu ich nicht mehr.
Wenn es geht, dann mach ich lieber "einfach". (auch wenn es 'ne nanosekunde langsamer sein mag)

Oh, Ich mache es genau umgekehrt. Bei jeder Lösung überlege ich erst, wie geht es am schnellsten und wenn das mit wenig Aufwand zu implementieren ist, mache ich es so...
Besondern, wenn ich erst eine Klasse erzeugen muss, mache ich es am liebsten anders.

Ich hatte ja mal vor Jahren geschrieben, wenn jeder Entwickler mal überlegen würde, wie es schneller geht, müssten wir heute nicht 10 cores on 5GHz nehmen und das gleiche zu erreichen,
wie vor zig Jahren mit Windows 3.11 und einem 486er...

Aber EGAL!

[himitsu]

Man muß es immer bissl abwägen.

Ist das jetzt kein Code, der Milliardenfach ausgeführt wird, dann ist es womöglich nicht schlimm, wenn er 'ne Millisekunde länger braucht.

Seit FastMM standardmäßig im Delphi ist,
dann kann man meißtens Glück haben und er hat noch genügend freie Flecken, wo alle Strings rein passen, womit nicht "wirklich" Speicher reserviert/freigegeben werden muß (in Windows)
Der Speicherverbrauch ist hier auch nur kurz bissl höher. (der String ist nicht lang und somit fällt es auch nicht wirklich auf zwischen all den Gigabyte)

Somit kann man sehr oft nach dem Motto "keep it simple" arbeiten.

Und optimieren kann man später immernoch.


OK, direkt extrem unperformanten Code zu verwenden, das versuche ich zu vermeiden, aber zwanghaft IMMER muß nicht sein.



Für eine Behandlung einer INI innerhalb der datenbank, hatte ich mir mal das Read/Write/Delete je als 1-Zeiler aus RegEx gebaut.
Anfangs war es so schön "einfach" und kurz ... OK, nach paar "Sonderfällen" ist der RegEx inzwischen ... naja ... mit einer Schleife in einer StoredProc ist es bestimmt übersichtlicher.

[KodeZwerg]

Da stimme ich zu.
Erstmal nach dem 'keep it simple stupid' Prinzip und später im Refactoring kann man immer noch abwägen ob hier oder da eine Optimierung angebracht sein sollte.

Okay, auf eindeutige Schwächen geh ich schon direkt ein.

Ausnahme bei mir ist wenn ich pur nativ programmiere (nonVcl), da ist mein verlangen zur bestmöglichen Performance von vornherein sehr hoch.

[hhcm]

Ich finde es ist nicht immer nötig alles mit Klassen zu machen oder es auf die letzte ms auszureizen.
Natürlich kommt es immer stark auf den Anwendungszweck an.
High-End ERP System, dann lieber OOP. Quick 'n Dirty Tool um was zu testen, da darf es schonmal nen 2-3 Zeiler direkt im OnClick eines Buttons sein.

Im Falle dieses Threads hätte ich mir die Stringliste auch gespart.

Result := TRegEx.Match(InputString, 'tvg-language=\"(.*?)\"').Groups[1].Value;

[himitsu]

Problem, wenn der Wert nicht in der Liste ist, dann raucht dein Code ab.
Die dagegen StringList gibt bei Nichtexistenz wortlos einen Leerstring raus.

Es gibt RegEx-Implementationen die ählich reagieren, aber standardmäßig ist hier dieses [1] ein potentielles risiko. (wenn man es nicht abfängt/prüft)

[Mavarik]

Zitat von KodeZwerg:

Erstmal nach dem 'keep it simple stupid' Prinzip und später im Refactoring kann man immer noch abwägen ob hier oder da eine Optimierung angebracht sein sollte.

Ja das wird immer so gesagt, aber sind wir doch mal ehrlich... Wenn Du Routine läuft, packt die keiner mehr an...

Wenn es bei einer großen Datei dann zu lange dauert, kommt eher ein "Bitte Warten" Fenster drum rum anstatt, vor schon mal die Routine 10x schneller zu machen.

Aber wir schweifen ab...

Mavarik

[hhcm]

Zitat von himitsu:

Problem, wenn der Wert nicht in der Liste ist, dann raucht dein Code ab.
Die dagegen StringList gibt bei Nichtexistenz wortlos einen Leerstring raus.

Ich wollte damit nicht den Einzeiler schmackhaft machen.
Da gehört z.B noch TRegEx.IsMatch vor.

TStringList als "PHP Explode" oder Parser zu nutzen ist jedenfalls (Achtung, freie Meinungsäußerung) ein no-go.

Lange rede etc. "Bestimmstes Wort auslesen" = Regex.