A
Christian211 schrieb:
Wenn die Speicherplätze wo der Zeiger hinzeigt verändert werden, dann ist bei allen Zeigern Schluß.
Ja, aber bei selbst erzeugten Zeigern kannst Du das auch selbst bestimmen, wann der Zeiger ungültig wird - bei c_str()
nicht. Du kannst Dir dazu auch mal die BCB-Hilfe zu AnsiString::c_str() anschauen (ist im Forum auch schon mehrfach
erwähnt worden).
Christian211 schrieb:
String ist die Klasse AnsiString der VCL und c_str() eine Methode dieser Klasse.
...und was gibt c_str() zurück? Wenn schon, dann so wie es Akari vorgeschlagen hat - obwohl ich die Lösung auch
nicht "schön" finde.
akari schrieb:
Aber man sollte generell direkte Zugriffe dem langsamen String-Absuchen vorziehen.
Vor absoluten Aussagen versuche ich mich möglichst zu hüten. Ich versuche zunächst immer ein schlüssiges Design zu
bekommen und schaue anschließend, ob das ganze effizient genug ist. Wenn man flexible dynamische Strukturen hat,
kommt man oft nur schwierig um solche langsamen Konstrukte herum. Mir ist auch Verständlichkeit und (Menschen-)Lesbarkeit
des Codes wichtig, weshalb ich eine lesbare Version zunächst einer (vermeintlich) schnellen Version vorziehe.
akari schrieb:
Genauso wie ich niemals TForm::FindComponent() verwenden würde. Ich bevorzuge Arrays ind Indizes.
Sag niemals nie
Wir haben hier eine Übersetzungskomponente gebaut, die automatisch Formulare übersetzt. Die einzelnen Komponenten werden
dabei über den Namen referenziert. Hier ist FindComponent() ungemein praktisch. Eine Lösung über Arrays o.ä. will mir
dazu nicht einfallen - außer einer for-Schleife und Vergleich auf Namen.
akari schrieb:
es funktioniert, wenn man sauber programmiert.
Könntest Du das ein wenig genauer ausführen?
Sauber programmieren heißt für mich nicht, irgendwo fragile Konstrukte zu verwenden, in die der nächste Kollege böse
hereinfallen kann - zumal der nächste Kollege ich selbst sein könnte...
Gruß,
Alexander