(Erledigt) Warum kommt hier variable already exists?

Previous topic - Next topic

Markus

Eigentlich wollte ich was anderes testen.

Code (glbasic) Select

TYPE TTest

x1
y1
x2
y2

FUNCTION ChangeViewPort: BYREF w,BYREF h

LOCAL x,y
x=self.x1
y=self.y1

w=(self.x2-self.x1)+1
h=(self.y2-self.y1)+1

IF self.y1=0 AND self.y2=0
VIEWPORT 0,0,-1,-1
ELSE
VIEWPORT x,y,w,h
ENDIF

ENDFUNCTION

ENDTYPE

LOCAL A AS TTest
A.x1=0
A.y1=0
A.x2=320
A.y2=320

LOCAL w,h
A.ChangeViewPort(w,h)

END



Quote
*** Configuration: WIN32 ***
precompiling:
GPC - GLBasic Precompiler V.9.829 SN:471f0175 - 2D, WIN32
"Test.gbas"(34) warning : variable already exists : w
"Test.gbas"(34) warning : variable already exists : h
Wordcount:15 commands
compiling:
C:\Users\Gang\AppData\Local\Temp\glbasic\gpc_temp0.cpp: In function `int __GLBASIC__::__MainGameSub_()':
C:\Users\Gang\AppData\Local\Temp\glbasic\gpc_temp0.cpp:113: error: `w' was not declared in this scope
C:\Users\Gang\AppData\Local\Temp\glbasic\gpc_temp0.cpp:113: error: `h' was not declared in this scope
*** FATAL ERROR - Bitte die Compiler-Ausgabe ins Forum kopieren

kanonet

Ich weiß nicht warum. Aber wenn du die Reihenfolge änderst, erst das Hauptprogramm, dann den Type (so wie man es auch meist macht), dann funktioniert es einwandfrei. Aber eigentlich sollte es auch so gehen, was solls, solange es geht wenn du es umdrehst. ;)

PS: normalerweise kommt diese Warnung, wenn du eine variable ein zweites mal deklarierst (ich muss das an einigen Stellen mit Globales tun, die in einer Lib noch einmal declariert werden). Ist aber nur eine Warnung, compilieren tut es trotzdem.
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

Markus

@kanonet
Finde ich zwar nicht logisch die Types nach unten zu tun aber ich mach das mal.

Ich habe bei dem GUI was ich grad mache ganz komische Nebenwirkungen das er beim
zuweisen einer variable mit self.mx1=0 mit dem ForEach außen durcheinander kommt ...
Und bei self.mx1=-1 geht die ForEach Schleife gar nicht mehr.
Das sind Variablen die neu sind und noch gar nicht benutzt werden!?
Habe nur 3 neue einer Struktur hinzu gefügt.
Wenn ich das nicht raus finde nerv ich wieder  :booze:

Markus

#3
@kanonet
Also wenn ich Module nutze kann ich die Types gar nicht runter setzen.
Ich glaube das Hauptprogramm steht immer unten beim compilieren.

EDIT:
so macht es keine Probleme weil die Variablen w & h dann eine Ebene tiefer sind klappt das.

Code (glbasic) Select

TYPE TTest

x1%
y1%
x2%
y2%

FUNCTION ChangeViewPort: BYREF w%,BYREF h%

w=(self.x2-self.x1)+1
h=(self.y2-self.y1)+1

IF self.y1=0 AND self.y2=0
VIEWPORT 0,0,-1,-1
ELSE
VIEWPORT self.x1,self.y1,w,h
ENDIF

ENDFUNCTION

ENDTYPE

MainLoop()
END

FUNCTION MainLoop:

LOCAL A AS TTest
A.x1=0
A.y1=0
A.x2=320
A.y2=320

LOCAL w%,h%
A.ChangeViewPort(w,h)

ENDFUNCTION

kanonet

Wieso kannst du einen Type dann nicht runter setzen? Bei mir steht das Hauptprogramm immer oben, Types und Functions immer unten oder in weiteren .gbas-Dateien. Funktioniert immer. Aber es sollte egal sein, ob es oben oder unten steht, ist den persönlichen Vorlieben überlassen.

Dein Problem im ersten Post liegt bei BYREF, ist entweder dem C Backend geschulded (kenne mich da nicht aus), oder ein Bug. Benennst du entweder w und h im Type, oder im Hauptprogramm um, dann funktioniert es. Zum Beispiel:
Code (glbasic) Select
TYPE TTest

x1
y1
x2
y2

FUNCTION ChangeViewPort: BYREF w,BYREF h

LOCAL x,y
x=self.x1
y=self.y1

w=(self.x2-self.x1)+1
h=(self.y2-self.y1)+1

IF self.y1=0 AND self.y2=0
VIEWPORT 0,0,-1,-1
ELSE
VIEWPORT x,y,w,h
ENDIF

ENDFUNCTION

ENDTYPE

LOCAL A AS TTest
A.x1=0
A.y1=0
A.x2=320
A.y2=320

LOCAL a,b
A.ChangeViewPort(a,b)

END

Ist jetzt nicht ideal, aber ich denke, du kannst damit leben. Wie gesagt, ich halte es für möglich, dass es sich hierbei um einen Bug handelt, aber nicht sicher. Kannst ja eine Bugmeldung schreiben.


Übrigens kleiner Tipp (hat jetzt nur eingeschränkt mit deinem Problem hier zu tun^^):
Wenn du eine Variable innerhalb einer Loop (z.B. WHILE-WEND, ...) deklarierst, dann bleibt sie nur gültig bis zum Ende der Loop. Beim nächsten durchlauf wird sie wieder neu deklariert und an dessen Ende wieder gelöscht. Wie du dir vorstellen kannst, kostet dies immer etwas Rechenzeit. Daher würde ich Variablen, die jeden Schleifendurchlauf gebraucht werden, immer bereits vor der Schleife deklarieren. Übrigens sind Variablen, die innerhalb von If-ENDIF  deklariert werden auch nur bis zum ENDIF (oder ELSE;...) gültig.
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

Markus

@kanonet
Hauptprogramm und Modul habe ich getrennt damit ich das woanders auch noch einbinden kann
also nun hab ich zwei Dateien.
Das Gui Modul besteht eigentlich nur aus einem Type mit Funktionen darin und ist quasi unten.

Angefangen hat es das ich bei den Variablen die Datentyen genau mit %#$ festlegen wollte
und da hat der Compiler angefangen zu meckern.
Diese automatische Deklaration schiebt was zwischen was ich nicht erwarte.
Dafür müßte ich mir im Temp Ordner den in C übersetzen Quelltext für den Compiler angucken.

Das mit dem While Wend ist gut zu wissen.

kanonet

Aufteilen auf mehrere Dateien ist immer gut, wobei es bei so einem kleinen (Test-) Projekt natürlich nicht nötig ist und auch so funktionieren sollte. Daher ja auch der Hinweis einfach die Namen zu ändern, schon gehts.

Autodeklaration ist scheiße, explizite Deklarationen FTW! Zwingt einen sich die Variablentypen genau zu überlegen und sauber zu programmieren, außerdem hilft es auch Tippfehler in Variablennamen schneller zu finden. Ich lasse explizite Deklarationen in praktische jedem größeren Projekt aktiviert. Strings müssen das $ immer dran haben, egal wann du sie nutzt. Integer brauchen das % nur bei der Deklaration, danach ist es dir überlassen ob du es weiterhin verwendest, oder nicht. Floats brauchen das # eigentlich nie, ist also dir überlassen, ob du es verwendest oder nicht. Gibst du bei der Deklaration nichts an, wird die variable immer zur Float. Aus Geschwindigkeits- und Speicherverbrauchsgründen solltest du wenn möglich immer Integer verwenden.
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

Markus

#7
Ok,hätte ich bei schreiben können das ich das wo anders ausgeschnitten habe zum testen  :-[
Die erzwungene Deklaration benutze ich immer.  8)
Kann man die Autodeklaration ausschalten ?

Wenn ich die Namen einfach ändere sind die Variablen aber nicht da wo ich die erwarte.

kanonet

verstehe ich nicht ganz, wenn du explizite Deklarationen verwendest, dann sind Autodeklarationen doch ausgeschaltet?!
Umschalten kannst du das jedenfalls unter Projekt -> Deklarationen -> Explizite Deklarationen
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

Markus

Explizite Deklarationen scheint ein Standartwert von neuen Projekten zu sein.
Im ersten Beispiel oben sieht man das der PreCompiler was hinzu zaubert.

kanonet

Jo, ist Standardwert, das führt manchmal zu Problemen, wenn man ein sehr altes Beispiel ausführen will, dass seine Variablen nicht deklariert. Damals gab es die Option explizite Deklarationen noch nicht, daher war sie nicht deaktiviert und wird in heutiger IDE automatische aktiviert -> Beispiel compiliert nicht und Neulinge fragen immer an, warum es nicht geht.^^

Quote from: Markus on 2012-Apr-22Im ersten Beispiel oben sieht man das der PreCompiler was hinzu zaubert.
Sorry, aber ich habe keine Ahnung, was du damit meinst...
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

Markus

Der sagt das w & h schon da ist was nicht stimmt.
Ich kenne byref sehr gut aus Visual Basic 6.
Statt ein Wert wird da einfach nur ein Pointer übergeben und dann kann man innen
am Wert drehen und oben drüber ist der auch geändert.

Haste Recht , die Hilfe könnte mal überarbeitet werden,
habe auch öffters copy paste gemacht und mußte da noch Local vorschreiben.
Ich wußte aber warum :-)

kanonet

Wie BYREF funktioniert ist mir schon klar. ;)
Code (glbasic) Select
Der sagt das w & h schon da ist was nicht stimmt.
Ja, aber das hat nicht unbedingt etwas mit Expliziter Deklaration zu tun und ist ja dann auch nicht der Grund für den Abbruch des Kompiliervorgangs. Außerdem habe ich dir ja zwei Workarounds genannt und empfohlen eine Bugmeldung zu schreiben (halte es für einen Bug).

Ja die Hilfe ist etwas angestaubt an manchen Ecken... an anderen Ecken sogar noch mehr.^^
Aber wenn du dann einmal ein Beispiel aktualisiert hast, könntest du es doch gleich einschicken, damit es geändert wird. Es arbeiten nur wenige Leute an der Hilfe und die haben auch eigentlich besseres zutun (Bugfixes oder neu Features für GLB entwickeln z.B.), da würd etwas Community Hilfe an der Hilfe sicher helfen (oder so^^).
Btw schon mal in das Anfänger Tutorial geschaut? Da wird noch mit LET gearbeitet, dass ist schon seit sehr vielen Jahren outdated, aber immer noch in der Hilfe. xD
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

BumbleBee

 :offtopic:

@Markus
Neuer Rekord: In einer Woche 75 Posts. Macht über 10 am Tag. Das hab ich in 8 Jahren hier nicht geschafft.   =D
The day will come...

CPU Intel(R) Core(TM) i5-3570k, 3.4GHz, AMD Radeon 7800 , 8 GB RAM, Windows 10 Home 64Bit

Schranz0r

I <3 DGArray's :D

PC:
AMD Ryzen 7 3800X 16@4.5GHz, 16GB Corsair Vengeance LPX DDR4-3200 RAM, ASUS Dual GeForce RTX™ 3060 OC Edition 12GB GDDR6, Windows 11 Pro 64Bit, MSi Tomahawk B350 Mainboard