Entwickler-Ecke :: Thema anzeigen - Konstanten-Deklaration durch eine Funktion

beastofchaos - So 13.03.11 13:57
Titel: Konstanten-Deklaration durch eine Funktion

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:

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:

...

uses
  ..., MMSystem;

...

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

...

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

MfG Beast

jaenicke - So 13.03.11 14:15

beastofchaos hat folgendes geschrieben :

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.

beastofchaos - So 13.03.11 14:24

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:

Delphi-Quelltext

1:
2:

const
  F: Extended = QueryPerformanceFrequency;

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

jaenicke hat folgendes geschrieben :

beastofchaos hat folgendes geschrieben :

Delphi-Quelltext

1:
2:

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

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 )

ALF - So 13.03.11 14:46

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 user profile icon

jaenicke doch geschrieben! Der Compiler fürt kein QuellCode aus!
Also muss eine Const auch definitiv sein!

Gruss ALf

LexXis - So 13.03.11 22:23

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:

Delphi-Quelltext

1:
2:

const
  MONTAG = $D00F;

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

Aber:

Delphi-Quelltext

1:
2:

const
  XTRALONGCHILICHEESE = SchaerfeempfindenVon(BenBE);

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ß

beastofchaos - So 13.03.11 22:52

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.

jaenicke - Mo 14.03.11 05:27

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. :lol:

elundril - Mo 14.03.11 09:54

jaenicke hat folgendes geschrieben :

elundril hat folgendes geschrieben :

dieses konzept gibt es bei delphi 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:

Quelltext

1:
2:

int AnzahlForenuser = 32485;
int AnzahlSuchfunktionNutzer = 400;

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

jaenicke - Mo 14.03.11 11:03

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. :gruebel:

Delphi-Quelltext

1:
2:
3:

var
  MyForm: TMyForm;
  MyGlobalShit: Integer = 0;

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.

elundril - Mo 14.03.11 12:40

jaenicke hat folgendes geschrieben :

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. :gruebel:

Delphi-Quelltext

1:
2:
3:

var
  MyForm: TMyForm;
  MyGlobalShit: Integer = 0;

Also bei Delphi 7 will der Compiler nicht kompilieren wenn ich ihm das als Input anbiete. Gibt jedes mal ne Fehlermeldung.

jaenicke hat folgendes geschrieben :

elundril hat folgendes geschrieben :

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

Naja, mit 0 eben und da auch nur die globalen. Es wäre recht hilfreich wenn mans selbst entscheiden kann, oder ist würd das ev. Probleme geben. Ich kenn das wie gesagt eben nur vom erzählen, ob es wirklich schneller ist, weiß ich nicht.

jaenicke hat folgendes geschrieben :

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.

[/quote]

Ohh, sorry, mein Fehler. :oops: Und klein Elundril merkte sich: Zuerst denken, dann posten. :mrgreen:

lg elundril

jaenicke - Mo 14.03.11 15:33

elundril hat folgendes geschrieben :

Also bei Delphi 7 will der Compiler nicht kompilieren wenn ich ihm das als Input anbiete. Gibt jedes mal ne Fehlermeldung.

Das geht auch bei Delphi 5 schon. Ich hoffe die Formularvariable war deutlich genug um zu zeigen, dass ich eine globale Variable meine?

Bei lokalen geht das natürlich nicht und da ist es auch wenig sinnvoll, da einzelne Methoden eh nie so lang sein sollten, dass man da den Überblick verliert. :mrgreen:

Mr_Emre_D - Mo 14.03.11 22:43

jaenicke hat folgendes geschrieben :

elundril hat folgendes geschrieben :

dieses konzept gibt es bei delphi nicht.

Geht immernoch: Compilerdirektive {$J-}{$J+} verwenden!

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:

const
  {$J+}
  x: Integer = 13;
  {$J-}

begin
  inc( x );
end.

Das ganze ist aber sehr sinnfrei! Anstatt const und den beiden Compilerdirektiven sollte man lieber var verwenden!

Zum ursprünlichen Problem: Du kannst das frühestens im Initialization und Finalization Bereich der Units machen!

MfG

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!