Hallo Leute,
Konstanten sind ein ziemich simples Thema, aber ich habe trotzdem ein Problem gefunden:

Bei mir ist es nicht möglich den Pfad durch eine Funktion in der Konstante "Path" zu speichern. Kann das Programm in dem Bereich vll auf solche externe Funktionen noch nicht zugreifen?
Hier der Quelltext:





Natürlich ginge das ganze noch in Formcreate, aber ich finde es sauberer, wenn es in den Konstanten deklariert ist.


MfG Beast

Vielleicht noch einmal mit Grundlagen beschäftigen?

beastofchaos hat folgendes geschrieben :

markieren Delphi-Quelltext     1: 2: const   s : String = ExtractFilePath(Application.ExeName);           // Soll den Pfad des Ordners der Exe-datei ermitteln

Naja, was ist denn eine Konstante? Richtig, ein Wert, der konstant bleibt.

So, jetzt kompilierst du die Exe. Nehmen wir einmal an das würde funktionieren, dann stünde da z.B. 'c:\test' drin. Jetzt kopierst du die Exe aber nach c:\programme... und was jetzt? Du merkst: Das ist nun einmal kein konstanter Wert, also wie sollte der als fester konstanter Wert in die Exe kompiliert werden?

Konstanten müssen auch genau das sein: konstant, damit sie beim Kompilieren berechnet und als kostanter Wert in die Exe geschrieben werden können.

Robert.Wachtel hat folgendes geschrieben :

Vielleicht noch einmal mit Grundlagen beschäftigen?

Was ist denn DA mein gravierender Fehler?
Darf man Konstanten nicht mit funktionen bestimmen, oder wie?
anderes Beispiel wäre.
Angenommen QueryPerformanceCoutner wäre eine funktion statt so einer sinnlosen Prozedur:



Es geht mir doch nur grundsätzlich darum - darf ich in DIESEM Abschnitt eine Funktion verwenden.

jaenicke hat folgendes geschrieben :

beastofchaos hat folgendes geschrieben : markieren Delphi-Quelltext     1: 2: const   s : String = ExtractFilePath(Application.ExeName);           // Soll den Pfad des Ordners der Exe-datei ermitteln Naja, was ist denn eine Konstante? Richtig, ein Wert, der konstant bleibt. So, jetzt kompilierst du die Exe. Nehmen wir einmal an das würde funktionieren, dann stünde da z.B. 'c:\test' drin. Jetzt kopierst du die Exe aber nach c:\programme... und was jetzt? Du merkst: Das ist nun einmal kein konstanter Wert, also wie sollte der als fester konstanter Wert in die Exe kompiliert werden? Konstanten müssen auch genau das sein: konstant, damit sie beim Kompilieren berechnet und als kostanter Wert in die Exe geschrieben werden können.

Das ist mir klar, aber er berechnet die Konstante doch bei jedem Programmstart neu und, wenn du es jetzt wo anders hinschiebst, und es dann startest, hast du auch den neuen Pfad automatisch...
Übrigens ist eine Konstante zwar konstant, aber nur die Programmzeit über... danach sind alle variablen und konstanten verschwunden ( kein programm, kein iwas )

Beim Compilieren wird diese Const an dieser Stelle gefixt!
Was du nun innerhalb deines Prog zur Laufzeit machst ist was ganz anderes!

Hat jaenicke doch geschrieben!
Gruss Alf

Achso, ihr meitn der fixed das nicht bei jedem Programmstart, sondern nur einmal beim Programmschreiben? Oh... )


Aber geht es denn jetzt grundsätzlich nicht mit Funktionen im Konstanten-Bereich oder geht das nur mit dieser Funktion nicht?

beastofchaos hat folgendes geschrieben :

Aber geht es denn jetzt grundsätzlich nicht mit Funktionen im Konstanten-Bereich oder geht das nur mit dieser Funktion nicht?

Das geht generell nicht, denn beim Kompilieren wird kein Code deines Programms ausgeführt.

Und wenn er dabei auf eine andere Unit zugreifen muss für die Funktion?

Andere Units werden schließlich "vorher" in uses schon gezeigt.

Kann nur ich Deinen Ausführungen nicht folgen?

Sonst könntest Du keine Zeile Prog schreiben wenn die IDE dir dies nicht zuverfügung stellen würde! Das ist ja das schöne daran das ich mir keinen Kopf machen muss wo sich welche Funktion in welcher Unit befindet! Den Rest macht für mich der Compiler!

Man muss es nur verstehen!

Auch hier noch mal, hat jaenicke doch geschrieben! Der Compiler fürt kein QuellCode aus!
Also muss eine Const auch definitiv sein!

Gruss ALf

ALF hat folgendes geschrieben :

Der Compiler fürt kein QuellCode aus! Also muss eine Const auch definitiv sein! Gruss ALf

Verstanden, Dankeschön xD
Ich machs dann in FormCreate

MfG Beast

Zitat:

Verstanden, Dankeschön xD Ich machs dann in FormCreate MfG Beast

Und was soll da passieren!!!
Gruss Alf

Na was wohl
Er liest den Pfas des order, wo die Exe liegt. Sort hab ich für mein Programm einige Sounds und Bilder liegen und im spiel wechselt das mal

Du wirst es mittlerweile wohl selbst herausgefunden haben, aber der Vollständigkeit halber nochmal:

Konstanten sind genau das: Konstant. Die ändern sich weder während des Kompilierens noch zur Runtime noch sonst wie. Sie behalten den Wert, der ihnen fix zugewiesen wird.
Kleines Beispiel:

Keiner mag Montage. Deswegen kann ich MONTAG als Konstante deklarieren - das wird sich voraussichtlich nie ändern.

Aber:

Das kann nicht funktionieren, weil niemand absehen kann wie scharf Ben seine Burger mag. Mal ganz davon abgesehen, dass ich beispielsweise die Schärfe vollkommen ausreichend finde. Hier liegt also kein konstanter Wert vor, sondern ein variabler.

Und genau da is dein Knackpunkt Nutz hierfür eine Variable, die lässt sich beim Ausführen beliebig ändern.

Gruß

LexXis hat folgendes geschrieben :

Du wirst es mittlerweile wohl selbst herausgefunden haben, aber der Vollständigkeit halber nochmal: Und genau da is dein Knackpunkt Nutz hierfür eine Variable, die lässt sich beim Ausführen beliebig ändern.

Genau deswegen kam ich doch auf Konstanten, weil es nicht verändern werden darf...das ist schließlich der Pfad.
Den kann man nicht während einer Ausführung eines Programmes ändern, wei dann müsste man ja das ganze Spiel verschieben können zur Laufzeit, da würde es aber sicher iwie Probleme geben.

Ich dachte, dass man Konstanten bei jedem Programmstart neu definieren kann, aber sie während des Programmes/ zur Laufzeit nicht verändert werden können durch iwelche Prozeduren/Funktionen, wie wenn man z.B. auf einen Button klickt.

Es wurde doch schon so erklärt, dass die Konstante nicht bei Programmstart gefixed wird, sondern wenn das Programm geschrieben wird... Ist aber auch egal, da keiner hier mich bis jetzt verstanden hat und ich hab ja das Thema shcon als beantwortet markiert. Ist ja auch jetzt geklärt, indem halt der Pfad variabel ist.

das ist der unterschied zwischen delphi und zb java. in java ist das final so das man die variable tatsächlich zur laufzeit genau einmal setzen kann. dieses konzept gibt es bei delphi nicht. wir verstehen dich auch was du von uns willst aber wir können die delphi-sprache leider nicht ändern.

lg elundril

This Signature-Space is intentionally left blank.
Bei Beschwerden, bitte den Beschwerdebutton (gekennzeichnet mit PN) verwenden.

elundril hat folgendes geschrieben :

dieses konzept gibt es bei delphi nicht.

In Delphi 1 konntest du es z.B. noch Konstanten zur Laufzeit verändern. Jetzt muss dafür die entsprechende Projektoption gesetzt werden (veränderbare typisierte Konstanten oder so). Das Konzept mit nur einmal ändern oder so gibt es in der Tat nicht.

Allerdings sehe ich darin keinen Sinn Konstanten veränderbar zu machen, denn dann sind es ja Variablen, nur dass dran steht es wären keine.

In C# gibt es übrigens beide Möglichkeiten: Man kann ein Symbol als const deklarieren, oder aber als static readonly. Im zweiten Fall können auch Objekte instanziert oder Funktionen aufgerufen werden. Wie oft sich der Rückgabewert dieser Funktion ändert, interressiert dabei keinen - er wird einfach einmal am Start ermittelt und festgehalten.

jaenicke hat folgendes geschrieben :

elundril hat folgendes geschrieben : dieses konzept gibt es bei delphi nicht. In Delphi 1 konntest du es z.B. noch Konstanten zur Laufzeit verändern. Jetzt muss dafür die entsprechende Projektoption gesetzt werden (veränderbare typisierte Konstanten oder so). Das Konzept mit nur einmal ändern oder so gibt es in der Tat nicht.

Typisierte Konstanten gibts in Delphi 7 zb auch noch. Muss man ebenfalls mit einem Compilerschalter aktiveren. Jedoch verhalten sie sich dann wie variablen, also können auch öfters geändert werden. Der einzige Vorteil von denen ist, das man ihnen beim erzeugen eben schon einen Wert zuweisen kann, so wie in C, C++, Java, wenn man Variablen nach diesem Schema erzeugt:



Und irgendwie geht mir das auch in Delphi ab. Einerseits weil es kürzer ist und man nie vergessen kann eine Variable zu initialisieren und andererseits hab ich mir sagen lassen das es schneller ist wenn man eine Variable beim Initialisieren schon mit einem Wert belegt als wenn man zuerst die Variable erzeugt und ihr erst dann einen Wert zuweist.

lg elundril

This Signature-Space is intentionally left blank.
Bei Beschwerden, bitte den Beschwerdebutton (gekennzeichnet mit PN) verwenden.

elundril hat folgendes geschrieben :

Der einzige Vorteil von denen ist, das man ihnen beim erzeugen eben schon einen Wert zuweisen kann, so wie in C, C++, Java, wenn man Variablen nach diesem Schema erzeugt:

Das geht in Delphi doch auch, nur eben nicht variable Werte.

elundril hat folgendes geschrieben :

andererseits hab ich mir sagen lassen das es schneller ist wenn man eine Variable beim Initialisieren schon mit einem Wert belegt als wenn man zuerst die Variable erzeugt und ihr erst dann einen Wert zuweist.

Globale Variablen und Felder eines Objekts werden immer bereits mit 0 vorinitialisiert. Nur lokale Variablen nicht.

elundril hat folgendes geschrieben :

Typisierte Konstanten gibts in Delphi 7 zb auch noch. Muss man ebenfalls mit einem Compilerschalter aktiveren.

Das meinte ich mit "jetzt muss dafür...".
Das geht in XE auch weiterhin, es ist nur nicht empfehlenswert das zu nutzen.