| |
|
|
Jac de Lad | Der Titel hat keine genauere Beschreibung zugelassen, also:
XPSE meckert Variablen an, die ich in einer Proc declariere und in einer anderen Proc, die die erste Proc aufruft, verwende. Beispiel: KompilierenMarkierenSeparieren Ich verstehe, den Hintergrund, würde mir aber, wenn möglich einen Schalter oder so wünschen, mit dem der Check umgangen werden kann, da ich solche Konstrukte in fast allen meinen Projekten problemlos verwende und die dann nur mit $noerr compilieren kann; dadurch gehen mir öfters mal andere, gravierende Fehler durch die Lappen.
Jac |
|
|
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE) Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 16.07.2008 ▲ |
|
|
|
|
| Richtig, a& ist nicht deklariert - also nicht lokal und nicht global.
XPSE beherrscht jedoch etwas das von XProfan keine Relevanz zugeordnet bekommt: Verschachtelte Prozedurendeklaration.
Hiernach kannst Du die Proc2 in der Proc1 definieren - und voila: XPSE wird die Abhängigkeit erkennen und sieht keinen Grund Dich auf einen möglichen Fehler hinzuweisen.
Somit ist a& auch logischer innerhalb von proc1 erreichbar. KompilierenMarkierenSeparieren Jac
Der Titel hat keine genauere Beschreibung zugelassen, also: XPSE meckert Variablen von einer anderen Proc an...
Ich hab den Titel mal auf Sichtbarkeit lokaler Variablen geändert. |
|
|
| |
|
|
|
Jac de Lad | Hm, klingt logisch. Aber die Proc2 wird manchmal auch von ner anderen Proc aufgerufen, die a& declariert hat. |
|
|
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE) Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 16.07.2008 ▲ |
|
|
|
|
| Das ist aber nichts was sich irgendwie schönreden liesse.
Dann einfacher und übersichtlicher gleich eine Globale statt eine lokal-definierte-als-Globale-missbrauchte... (oder eben als Param) |
|
|
| |
|
|
|
Jac de Lad | Dann hätte ich etliche globale Variablen mehr (und soweit ich weiß heißt es immer so viel wie möglich lokal, so wenig wie nötig global). Parameter geht auch nicht, weil ich auch in die Variablen reinschreibe. Da müsste ich die Addressen übergeben. |
|
|
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE) Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 16.07.2008 ▲ |
|
|
|
|
Rolf Koch | Hey Jac Du hast Profan11! Was hindert Dich daran global zu arbeiten? Hast doch mit 11 genügend Freiheiten an Variablen: Auszug XPROFAN 11 Help: 2 Mia Variablen je Typ - sollte doch reichen oder? |
|
|
| |
|
|
|
| Jac
Dann hätte ich etliche globale Variablen mehr (und soweit ich weiß heißt es immer so viel wie möglich lokal, so wenig wie nötig global).
Hier bringst was durcheinander.
Es gilt Globale zu vermeiden zwecks besserer Übersicht (und in anderen Sprachen noch aus anderen Gründen) - in Deinem Nutzungsfall gilt es erst einmal für eine nachvollziehbare Übersicht Globale zu deklarieren.
Das Grundproblem hierbei ist das Du Funktionen/Prozeduren eher als *Makros missbrauchst.
*Eingabewerte sind nicht ausschließlich Parameter und/oder Ausgabewerte sind nicht ausschließlich Rückgabewerte.
Dann aber saubere Globale bzw. Klassen. |
|
|
| |
|
|
|
Jac de Lad | @iF: Joar, so kann mans auch sagen. @Rofl: Nee, das war nicht der springende Punkt. Es ging mir ums Prinzip Variablen nur so lange zu haben, wie nötig. Die globalen sind immer da. Ich kanns jetzt auch nicht so genau beschreiben... |
|
|
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE) Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 16.07.2008 ▲ |
|
|
|
|
Rolf Koch | *lol* Jac: ROFL und ROLF sind zwei paar Schuhe. Aber mach Dir nix draus, denn immer wenn ich ROFL lese, dann fühle ich mich angesprochen |
|
|
| |
|
|
|
| Dabei, seit XProfan11 können Funktionen Arrays zurückliefern...
lecker... [...] |
|
|
| |
|
|