AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

String 2 PChar ?

Ein Thema von andi_hauser · begonnen am 9. Okt 2002 · letzter Beitrag vom 10. Okt 2002
Antwort Antwort
Seite 1 von 2  1 2      
andi_hauser
(Gast)

n/a Beiträge
 
#1

String 2 PChar ?

  Alt 9. Okt 2002, 01:15
Wie kan ich einen String in ein PChar Format bekommen. Brauche diese Umwandlung für ein schnelles Kopieren von Files.

Folgende Zeile funktioniert aus genau diesem Grund nicht. (eh klar!)

Copyfile('C:\autoexec.bat',Edit1.text,alreadyexist s);

ThanX4Help
  Mit Zitat antworten Zitat
Christian Seehase
(Co-Admin)

Registriert seit: 29. Mai 2002
Ort: Hamburg
11.116 Beiträge
 
Delphi 11 Alexandria
 
#2
  Alt 9. Okt 2002, 01:46
Moin Andi,

das geht einfach so:
Code:
  Copyfile('C:\autoexec.bat',PChar(Edit1.text),alreadyexists);
Einen Thread, wo's um das Kopieren geht, hatten wir gerade vor ein paar Tagen.
Such' am Besten mal nach SHFileOperation.
Tschüss Chris
Die drei Feinde des Programmierers: Sonne, Frischluft und dieses unerträgliche Gebrüll der Vögel.
Der Klügere gibt solange nach bis er der Dumme ist
  Mit Zitat antworten Zitat
Benutzerbild von Luckie
Luckie

Registriert seit: 29. Mai 2002
37.621 Beiträge
 
Delphi 2006 Professional
 
#3
  Alt 9. Okt 2002, 02:13
Oder:
Code:
Copyfile('C:\autoexec.bat',@Edit1.text[1],alreadyexists);
Mir wurde mal gesagt, das mit PChar wÜrde nur wegen der Compiler Magic funktionieren.
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
Benutzerbild von sakura
sakura

Registriert seit: 10. Jun 2002
Ort: Unterhaching
11.412 Beiträge
 
Delphi 12 Athens
 
#4
  Alt 9. Okt 2002, 09:39
@Luckie: Bist Du Dir sicher, dass Dein Ansatz immer einwandfrei funktionert Immerhin hat ein Editfeld i.A. kein #0 Zeichen am Ende, woran ja auch das Ende eines PChar erkannt wird.
Daniel Lizbeth
Ich bin nicht zurück, ich tue nur so
  Mit Zitat antworten Zitat
Benutzerbild von Motzi
Motzi

Registriert seit: 6. Aug 2002
Ort: Wien
598 Beiträge
 
Delphi XE2 Professional
 
#5
  Alt 9. Okt 2002, 11:41
Theoretisch funktionieren beide Varianten... das mit dem @..[1] wird aber bei einer Objekt-Eigenschaft funktionieren, da eine Eigenschaft schließlich nur eine Schnittstelle über Zugriffsmethoden auf eine private Variable darstellt kann auch keine Adresse ermittelt werden.

Aber es gibt auch andere Unterschiede zwischen PChar(..) und @..[1]. Mann muss nur mal ein paar Test mit einer API-Funktion machen, die einen String in einem PChar ablegt:

Version1:
Code:
var
  String1, String2: String;

String1 := 'Test';
String2 := String1;

IrgendeineAPIFunktionDieDatenImStringAblegt(PChar(String1));

ShowMessage(String1);
ShowMessage(String2);
Version2:

Code:
var
  String1, String2: String;

String1 := 'Test';
String2 := String1;

IrgendeineAPIFunktionDieDatenImStringAblegt(@String1[1]));

ShowMessage(String1);
ShowMessage(String2);
Die ergebnisse werden sich unterscheiden.. ein einem Fall sind String1 und String2 ident (obwohl nur String1 über die API-Funktion geändert wurde). Ich bin mir zwar nicht ganz sicher wie der Code dazu ausschaun muss (eventuell muss man ihn ein bisschen anpassen) aber ich hab schonmal ein paar Tests gemacht mit genau diesem Ergebnis. Aber genau um diesen Fall zu verhindern gibt es die Funktion UniqueString.
Manuel Pöter
  Mit Zitat antworten Zitat
Benutzerbild von sakura
sakura

Registriert seit: 10. Jun 2002
Ort: Unterhaching
11.412 Beiträge
 
Delphi 12 Athens
 
#6
  Alt 9. Okt 2002, 11:53
Zitat von Motzi:
Die ergebnisse werden sich unterscheiden.. ein einem Fall sind String1 und String2 ident (obwohl nur String1 über die API-Funktion geändert wurde). Ich bin mir zwar nicht ganz sicher wie der Code dazu ausschaun muss (eventuell muss man ihn ein bisschen anpassen) aber ich hab schonmal ein paar Tests gemacht mit genau diesem Ergebnis. Aber genau um diesen Fall zu verhindern gibt es die Funktion UniqueString.
Meine Ergebnisse (nutze GetTempPath):

Version 1: Access Violation
Version 2: String 1 hat das Ergebnis, String 2 den ursprünlichen Wert.

Insgesamt, wie erwartet, da dass Casten eines Strings in ein PChar für variable Parameter nicht als sicher gilt.
Daniel Lizbeth
Ich bin nicht zurück, ich tue nur so
  Mit Zitat antworten Zitat
Christian Seehase
(Co-Admin)

Registriert seit: 29. Mai 2002
Ort: Hamburg
11.116 Beiträge
 
Delphi 11 Alexandria
 
#7
  Alt 9. Okt 2002, 14:01
Moin Sakura,

die Variante mit @...[1] funktioniert immer, da Delphi einen String automatisch mit #00 beendet.

Ich hab's jetzt auch einmal mit GetTempPath ausprobiert: Kein Problem.

Allerdings hatte mich das Ergebnis doch verblüfft.
Zuerst hatte ich an ein Problem mit der Implementation von GetTempPath durch Borland gedacht, und mir die Funktion noch einmal selber importiert. Ergebnis: Es trat das gleiche Problem auf.

Daraufhin habe ich mir das Ganze mal im CPU Fenster angesehen. In der PChar-Variante wird LStrToPChar aufgerufen, was dann dafür sorgt, dass String1 und String2 den gleichen Wert bekommen, in der @..[1]-Version hingegen, wird, an der gleichen Stelle, UniqueString aufgerufen.
Als ich dann mal einen kleinen Blick in die Hilfe zu UniqueString geworfen hatte, kam ich zu dem Schluss, künftig auf die Parameterübergabe, im Zusammenhang mit API's auf PChar zu verzichten, falls ich denn eine String Variable übergeben will
Die @..[1] Variante ist wohl die einzig Richtige, zumindest, wenn man nicht selber zusätzlich UniqueString aufrufen will.
Ein Problem wird's allerdings erst, wenn, wie Motzi sagte, die Funktion etwas in den String schreiben muss.
Tschüss Chris
Die drei Feinde des Programmierers: Sonne, Frischluft und dieses unerträgliche Gebrüll der Vögel.
Der Klügere gibt solange nach bis er der Dumme ist
  Mit Zitat antworten Zitat
Benutzerbild von Luckie
Luckie

Registriert seit: 29. Mai 2002
37.621 Beiträge
 
Delphi 2006 Professional
 
#8
  Alt 9. Okt 2002, 14:10
Das stammt übrigens von Assarabad. Er hatte mich mal darauf angesprochen, weil ich in einem Programm immer mit PChar gecastet hatte.
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
Benutzerbild von sakura
sakura

Registriert seit: 10. Jun 2002
Ort: Unterhaching
11.412 Beiträge
 
Delphi 12 Athens
 
#9
  Alt 9. Okt 2002, 14:13
Zitat von Luckie:
Das stammt übrigens von Assarabad. Er hatte mich mal darauf angesprochen, weil ich in einem Programm immer mit PChar gecastet hatte.
Das casten mit PChar hat aber auch seine Berechtigung. Zum Beispiel, wenn man davon ausgehen kann, das der String nicht durch die aufgerufene Methode manipuliert wird. Dann spart man dadurch natürlich wertvolle Processorresourcen.
Daniel Lizbeth
Ich bin nicht zurück, ich tue nur so
  Mit Zitat antworten Zitat
Christian Seehase
(Co-Admin)

Registriert seit: 29. Mai 2002
Ort: Hamburg
11.116 Beiträge
 
Delphi 11 Alexandria
 
#10
  Alt 9. Okt 2002, 17:41
Moin Sakura,

Zitat:
Dann spart man dadurch natürlich wertvolle Processorresourcen.
Kommt natürlich darauf an, wie gross der Unterschied in der Prozessorauslastung zwischen UniqueString und LStrToPChar ist, denn eine von Beiden wird ja auf jeden Fall aufgerufen.
Und so in den Einzelheiten habe ich mir den Ablauf denn auch nicht angesehen.

Allerdings wird man, zumindest wenn man selber API Strukturen deklarieren will, nicht um PChar rumkommen können.
Tschüss Chris
Die drei Feinde des Programmierers: Sonne, Frischluft und dieses unerträgliche Gebrüll der Vögel.
Der Klügere gibt solange nach bis er der Dumme ist
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:34 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz