Tag Eigenschaft und Zeiger?
-
Hallo
AnsiString Text = "Test"; BitBtn1->Tag = reinterpret_cast<int> (&Text); // Adresse des AnsiStrings an Tag übergeben AnsiString Text2 = *(reinterpret_cast<AnsiString*> (BitBtn1->Tag)); // Aus Tag wieder AnsiString kopierenAber Achtung, Text muß in der gesamten Zeit, wo du auf den Tag zugreifen könntest, gültig sein!
bis bald
akari
-
Danke!

-
Ist sowas eigentlich sicher?
Mal ganz abgesehen davon, dass ich nicht von mir behaupten kann, ein Freund von diesen Tag-Lösungen zu sein,
finde ich auch, dass es klarere Lösungen gibt.
Wenn man schon unbedingt die Tag-Eigenschaft verwenden will, würde ich mir eher eine Lösung mit einer
StringList vorstellen.
Möglich wäre auch sowas:TStringList* buttonTexts = new TStringList(); for (/* alle Buttons */) buttonTexts->Values[Button->Name] = "mein Text, den ich mit diesem Button assozieren möchte";In einer Ereignisbehandlungsroutine kann man dann über Sender wieder an den Namen kommen.
Die Lösung funktioniert auch für andere TControl-Abkömmlinge, da alle die Name-Eigenschaft haben.
Da Controls innerhalb eines Formulars eindeutige Namen haben müssen, sollte das eindeutig sein.Gruß,
Alexander
-
Hallo
sicher, eine TStringList und die Verwendung des entsprechenden String-Index für Tag ist auch keine schlechte Idee.
Die cast-Methode ist grundsätzlich sicher, wenn auch nicht schön.
Der Nachteil deiner zweiten Methode mit dem Namen in der StringList ist, das das Suchen per Namen länger dauert als der Zugriff über Adresse oder Index.bis bald
akari
-
Christian211 schrieb:
String text="Hallo Welt";
Button->Tag=(int)text.c_str();Geht das so??
Ich dachte .c_str() würde irgenwie nur einen "temporären" Zeiger liefern.Klärt mich auf

mfg
xXx
-
Hallo
@ -=]xXx[=- :
das geht, solange text selber gültig ist und nicht verändert wird.bis bald
akari
-
akari schrieb:
Der Nachteil deiner zweiten Methode mit dem Namen in der StringList ist, das das Suchen per Namen länger dauert als der Zugriff über Adresse oder Index.
Wirst Du das spüren?
-=]xXx[=- schrieb:
Ich dachte .c_str() würde irgenwie nur einen "temporären" Zeiger liefern.
Dachte ich auch. Die Lösung würde ich bei mir nicht einbauen.
Meiner Meinung nach widerspricht dies auch der AussageChristian211 schrieb:
Wenn du die VCL benutzt solltest du mit AnsiString (String) arbeiten
Gruß,
Alexander
-
akari schrieb:
das geht, solange text selber gültig ist und nicht verändert wird.
Mit anderen Worten: Glücksspiel

Gruß,
Alexander
-
Mit anderen Worten: Glücksspiel
Das trifft wohl auf alle Zeiger zu. Wenn die Speicherplätze wo der Zeiger hinzeigt verändert werden, dann ist bei allen Zeigern Schluß.
Meiner Meinung nach widerspricht dies auch der Aussage
????
String ist die Klasse AnsiString der VCL und c_str() eine Methode dieser Klasse.
-
Alexander Kempf schrieb:
akari schrieb:
Der Nachteil deiner zweiten Methode mit dem Namen in der StringList ist, das das Suchen per Namen länger dauert als der Zugriff über Adresse oder Index.
Wirst Du das spüren?
Bei diesem beispiel vielleicht nicht. Aber man sollte generell direkte Zugriffe dem langsamen String-Absuchen vorziehen. Genauso wie ich niemals TForm::FindComponent() verwenden würde. Ich bevorzuge Arrays ind Indizes.
Alexander Kempf schrieb:
-=]xXx[=- schrieb:
Ich dachte .c_str() würde irgenwie nur einen "temporären" Zeiger liefern.
Dachte ich auch. Die Lösung würde ich bei mir nicht einbauen.
Ich würde das bei mir auch nicht einbauen. Aber es funktioniert, wenn man sauber programmiert.
bis bald
akari
-
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