Include, Globale Variablen & Private

Übersicht

BlitzMax, BlitzMax NG

Beginners-Corner

	Tritium Betreff: Include, Globale Variablen & Private	Sa, Apr 16, 2011 23:57 Antworten mit Zitat
N'Abend allerseits, seit gestern habe ich folgendes Problem: Ich möchte mein Programm in mehrere logische Stücke aufteilen, die dann in einer zentralen Datei eingebunden werden. Gleichzeitig gibt es Globale Variablen, die sowohl in der Hauptdatei als auch in den Unterdateien benutzt werden sollen. Include möchte ich möglichst vermeiden, da ich mir sonst den Einsatz von Private überflüssig mache. Wie schaffe ich es also, dass ich gleichzeitig Private verwenden und in allen Dateien auf die globalen Variablen zugreifen kann? Schonmal vielen Dank für die Hilfe!

Tritium

Betreff: Include, Globale Variablen & Private

Sa, Apr 16, 2011 23:57
Antworten mit Zitat

N'Abend allerseits,

seit gestern habe ich folgendes Problem:
Ich möchte mein Programm in mehrere logische Stücke aufteilen, die dann in einer zentralen Datei eingebunden werden. Gleichzeitig gibt es Globale Variablen, die sowohl in der Hauptdatei als auch in den Unterdateien benutzt werden sollen. Include möchte ich möglichst vermeiden, da ich mir sonst den Einsatz von Private überflüssig mache.

Wie schaffe ich es also, dass ich gleichzeitig Private verwenden und in allen Dateien auf die globalen Variablen zugreifen kann? Schonmal vielen Dank für die Hilfe! Smile

	-Phoenix-	So, Apr 17, 2011 0:14 Antworten mit Zitat
Wenn du diese variablen überall nutzen willst wirst du wohl oder über bei diesen variablen auf private verzichten müssen wenn sie aber nur an gewissen stellen nötig sind, kannst du die variablen ja mit einer function/method nutzen indem du sie als argument mitschickst es kommt drauf an wie du es machen willst (du kannst übrigens private für einige globals haben und public für andere, bist nicht gezwungen alle globals gleich private zu machen)

-Phoenix-

So, Apr 17, 2011 0:14
Antworten mit Zitat

Wenn du diese variablen überall nutzen willst wirst du wohl oder über bei diesen variablen auf private verzichten müssen

wenn sie aber nur an gewissen stellen nötig sind, kannst du die variablen ja mit einer function/method nutzen indem du sie als argument mitschickst

es kommt drauf an wie du es machen willst
(du kannst übrigens private für einige globals haben und public für andere, bist nicht gezwungen alle globals gleich private zu machen)

	Tritium	So, Apr 17, 2011 0:29 Antworten mit Zitat
Die globalen Variablen möchte ich nicht Private machen, es geht um Types. Hab ich nicht ganz verständlich ausgedrückt, sorry Mh, ich weiß nicht ganz, wie ich das Problem beschreiben soll... Ich möchte in der Hauptdatei meine globalen Variablen definieren, die auch Types sein können, die in den Unterdateien definiert sind. Dazu muss ich die Unterdateien logischerweise in der Hauptdatei einbinden. Nun habe ich in den Unterdateien aber manche Types als Private deklariert, da sie nur innerhalb der entsprechenden Unterdatei von Bedeutung sind und man sie deshalb in der Hauptdatei nicht sehen soll. Gleichzeitig benötigt die Unterdatei einige der globalen Variablen, die ich in der Hauptdatei definiere. Ich definiere sie dort, da es durchaus sein kann, dass Unterdatei a auf eine globale Variable zugreift, die von einem Typ ist, der in Unterdatei b definiert wird. Nun stehe ich aber vor einem Dilemma: 1) Ich binde die Unterdateien per Include in der Hauptdatei ein, dann können die Unterdateien auf die in der Hauptdatei definierten globalen Variablen zugreifen, dafür verliert aber das in der Unterdatei verwendete Private seine Bedeutung --> Ich sehe in der Hauptdatei Types, die in der Unterdatei eigentlich als Private definiert wurden. 2) Ich binde die Unterdateien per Import in der Hauptdatei ein, dann sind die in den Unterdateien als Private definierten Types in der Hauptdatei nicht sichtbar, dafür wissen die Unterdateien nichts von der Existenz der in der Hauptdatei definierten globalen Variablen --> Auch Mist Ich bin mir nicht ganz sicher, ob das Klarheit schafft, aber besser kann ich es grade nicht formulieren

Tritium

So, Apr 17, 2011 0:29
Antworten mit Zitat

Die globalen Variablen möchte ich nicht Private machen, es geht um Types. Hab ich nicht ganz verständlich ausgedrückt, sorry Confused

Mh, ich weiß nicht ganz, wie ich das Problem beschreiben soll... Ich möchte in der Hauptdatei meine globalen Variablen definieren, die auch Types sein können, die in den Unterdateien definiert sind. Dazu muss ich die Unterdateien logischerweise in der Hauptdatei einbinden. Nun habe ich in den Unterdateien aber manche Types als Private deklariert, da sie nur innerhalb der entsprechenden Unterdatei von Bedeutung sind und man sie deshalb in der Hauptdatei nicht sehen soll. Gleichzeitig benötigt die Unterdatei einige der globalen Variablen, die ich in der Hauptdatei definiere. Ich definiere sie dort, da es durchaus sein kann, dass Unterdatei a auf eine globale Variable zugreift, die von einem Typ ist, der in Unterdatei b definiert wird. Nun stehe ich aber vor einem Dilemma:
1) Ich binde die Unterdateien per Include in der Hauptdatei ein, dann können die Unterdateien auf die in der Hauptdatei definierten globalen Variablen zugreifen, dafür verliert aber das in der Unterdatei verwendete Private seine Bedeutung --> Ich sehe in der Hauptdatei Types, die in der Unterdatei eigentlich als Private definiert wurden.
2) Ich binde die Unterdateien per Import in der Hauptdatei ein, dann sind die in den Unterdateien als Private definierten Types in der Hauptdatei nicht sichtbar, dafür wissen die Unterdateien nichts von der Existenz der in der Hauptdatei definierten globalen Variablen --> Auch Mist

Ich bin mir nicht ganz sicher, ob das Klarheit schafft, aber besser kann ich es grade nicht formulieren Confused

	-Phoenix-	So, Apr 17, 2011 0:50 Antworten mit Zitat
Ich würde in dem fall das Private weglassen und include benützen, ich kenn keinen weg bei IMPORT eine globale variabel zu nutzen bei import kann nur der die importiert die functionen globale und types der importierte datei nutzen, die importierte datei muss ohne information von aussen auskommen daher kenn ich kein weg das zu erreichen, aber vielleicht weiss jemand anderes ja einen weg

-Phoenix-

So, Apr 17, 2011 0:50
Antworten mit Zitat

Ich würde in dem fall das Private weglassen und include benützen, ich kenn keinen weg bei IMPORT eine globale variabel zu nutzen

bei import kann nur der die importiert die functionen globale und types der importierte datei nutzen, die importierte datei muss ohne information von aussen auskommen

daher kenn ich kein weg das zu erreichen, aber vielleicht weiss jemand anderes ja einen weg

	Thunder	So, Apr 17, 2011 20:47 Antworten mit Zitat
Ich habe mich (unter anderem für mein Tutorial) eingehend mit BlitzMax' Innenleben und mit dem generierten Assemblercode beschäftigt. Das Problem bei der Benutzung von globalen Variablen mit Import in zwei Richtungen ist der BlitzMax-Compiler: BlitzMax: [AUSKLAPPEN] [EINKLAPPEN] 'main.bmx SuperStrict Import "imp.bmx" Global x:Int=1337 Print y BlitzMax: [AUSKLAPPEN] [EINKLAPPEN] 'imp.bmx SuperStrict Global y:Int=7331 Print x Hier regt sich BlitzMax auf, weil es einzeln beide Dateien kompiliert und in der zweiten Datei nirgends festgelegt ist, wo das x herkommt. Daher liegt es nahe, x (in imp.bmx) als extern zu deklarieren. Jetzt gibt es einen "Duplicate Identifier"-Error, weil der Compiler - nur so kann ich mir das erklären - die zwei Dateien nicht hintereinander kompiliert, sondern mit der ersten beginnt und dann beim Import mit der zweiten beginnt und alle globalen Variablen in dieselbe Variablenliste aufnimmt -> x kommt einmal als intern deklarierte und einmal als extern deklarierte Variable vor. Es gibt eine Möglichkeit, den Compiler "auszutricksen". Dazu schreibt man: BlitzMax: [AUSKLAPPEN] [EINKLAPPEN] 'imp.bmx SuperStrict Global y:Int=7331 Extern Global impbmx_x:Int="bb_x" 'man nehme einen Variablennamen, der in keiner anderen Datei vorkommt 'und leite ihn auf x um. Dazu verwendet man das Präfix bb_ (weil der Compiler alle 'Variablen mit ihm versieht) EndExtern Print impbmx_x Es gibt keine mir bekannte Möglichkeit, die es erlaubt, in der Importdatei auch x als Variablennamen zu verwenden. Das ganze müsste mit Funktionen genauso funktionieren, bei Types bin ich mir nicht sicher. mfg Thunder
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Thunder

So, Apr 17, 2011 20:47
Antworten mit Zitat

Ich habe mich (unter anderem für mein Tutorial) eingehend mit BlitzMax' Innenleben und mit dem generierten Assemblercode beschäftigt. Das Problem bei der Benutzung von globalen Variablen mit Import in zwei Richtungen ist der BlitzMax-Compiler:
BlitzMax: [AUSKLAPPEN]

'main.bmx
SuperStrict
Import "imp.bmx"
Global x:Int=1337
Print y

BlitzMax: [AUSKLAPPEN]

'imp.bmx
SuperStrict
Global y:Int=7331
Print x

Hier regt sich BlitzMax auf, weil es einzeln beide Dateien kompiliert und in der zweiten Datei nirgends festgelegt ist, wo das x herkommt.
Daher liegt es nahe, x (in imp.bmx) als extern zu deklarieren.
Jetzt gibt es einen "Duplicate Identifier"-Error, weil der Compiler - nur so kann ich mir das erklären - die zwei Dateien nicht hintereinander kompiliert, sondern mit der ersten beginnt und dann beim Import mit der zweiten beginnt und alle globalen Variablen in dieselbe Variablenliste aufnimmt -> x kommt einmal als intern deklarierte und einmal als extern deklarierte Variable vor.
Es gibt eine Möglichkeit, den Compiler "auszutricksen". Dazu schreibt man:
BlitzMax: [AUSKLAPPEN]

'imp.bmx
SuperStrict
Global y:Int=7331
Extern
        Global impbmx_x:Int="bb_x"
        'man nehme einen Variablennamen, der in keiner anderen Datei vorkommt
        'und leite ihn auf x um. Dazu verwendet man das Präfix bb_ (weil der Compiler alle
        'Variablen mit ihm versieht)
EndExtern
Print impbmx_x

Es gibt keine mir bekannte Möglichkeit, die es erlaubt, in der Importdatei auch x als Variablennamen zu verwenden.
Das ganze müsste mit Funktionen genauso funktionieren, bei Types bin ich mir nicht sicher.

mfg Thunder

Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

	BladeRunner Moderator	So, Apr 17, 2011 20:56 Antworten mit Zitat
Es ist ja auch nicht weiter verwunderlich, da ein Import ja ein Stück in sich geschlossenen Code einbinden soll. Der Vorteil an Imports liegt ja gerade darin dass schon vorgefertigte Objektdateien verwendet werden können - die Compilezeit ist also massiv reduziert da die Imports nur noch gelinkt werden müssen. Zugegeben ist das Private-Public-Verhalten von BMax hier ein Hemmschuh. Aber Import funzt wie es soll - zirkuläre Imports können auch durch anderes Design vermieden werden.
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

So, Apr 17, 2011 20:56
Antworten mit Zitat

Es ist ja auch nicht weiter verwunderlich, da ein Import ja ein Stück in sich geschlossenen Code einbinden soll. Der Vorteil an Imports liegt ja gerade darin dass schon vorgefertigte Objektdateien verwendet werden können - die Compilezeit ist also massiv reduziert da die Imports nur noch gelinkt werden müssen.
Zugegeben ist das Private-Public-Verhalten von BMax hier ein Hemmschuh. Aber Import funzt wie es soll - zirkuläre Imports können auch durch anderes Design vermieden werden.

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	Tritium	Mo, Apr 18, 2011 0:25 Antworten mit Zitat
@Thunder: Dein Code ergibt bei mir leider nur folgendes: Code: [AUSKLAPPEN] [EINKLAPPEN] Building main Compiling:imp.bmx flat assembler version 1.69.14 (1603110 kilobytes memory) 3 passes, 2597 bytes. Compiling:main.bmx flat assembler version 1.69.14 (1603722 kilobytes memory) C:/Programme/BlitzMax/.bmx/main.bmx.gui.debug.win32.x86.s [69]: _bb_x: error: symbol already defined. Build Error: Failed to assemble C:/Programme/BlitzMax/.bmx/main.bmx.gui.debug.win32.x86.s Process complete Bladerunner hat Folgendes geschrieben: Es ist ja auch nicht weiter verwunderlich, da ein Import ja ein Stück in sich geschlossenen Code einbinden soll. [...] Zugegeben ist das Private-Public-Verhalten von BMax hier ein Hemmschuh. Aber Import funzt wie es soll - zirkuläre Imports können auch durch anderes Design vermieden werden. Ja, mir war von vornherein bewusst, dass Import für so etwas nicht 100%ig richtig ist. Im Prinzip suche ich sowas wie ein 'Include', das Private berücksichtigt - also kurz gesagt (normal) funktionierendes Private/Public...

Tritium

Mo, Apr 18, 2011 0:25
Antworten mit Zitat

@Thunder: Dein Code ergibt bei mir leider nur folgendes:
Code: [AUSKLAPPEN]

Building main
Compiling:imp.bmx
flat assembler version 1.69.14 (1603110 kilobytes memory)
3 passes, 2597 bytes.
Compiling:main.bmx
flat assembler version 1.69.14 (1603722 kilobytes memory)
C:/Programme/BlitzMax/.bmx/main.bmx.gui.debug.win32.x86.s [69]:
_bb_x:
error: symbol already defined.
Build Error: Failed to assemble C:/Programme/BlitzMax/.bmx/main.bmx.gui.debug.win32.x86.s
Process complete

Bladerunner hat Folgendes geschrieben:

Es ist ja auch nicht weiter verwunderlich, da ein Import ja ein Stück in sich geschlossenen Code einbinden soll. [...] Zugegeben ist das Private-Public-Verhalten von BMax hier ein Hemmschuh. Aber Import funzt wie es soll - zirkuläre Imports können auch durch anderes Design vermieden werden.

Ja, mir war von vornherein bewusst, dass Import für so etwas nicht 100%ig richtig ist. Im Prinzip suche ich sowas wie ein 'Include', das Private berücksichtigt - also kurz gesagt (normal) funktionierendes Private/Public... Confused

	Thunder	Mo, Apr 18, 2011 11:57 Antworten mit Zitat
@Tritium: Danke für den Tipp. Im Debugmodus scheint es nicht zu funktionieren. Da muss man in der main.bmx ein NoDebug unter das SuperStrict stellen (das nimmt der Hauptdatei aber die Debugfunktionalitäten): BlitzMax: [AUSKLAPPEN] [EINKLAPPEN] 'main.bmx (Debugmodus) SuperStrict NoDebug Import "imp.bmx" Global x:Int=1337 Print y mfg Thunder
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Thunder

Mo, Apr 18, 2011 11:57
Antworten mit Zitat

@Tritium: Danke für den Tipp. Im Debugmodus scheint es nicht zu funktionieren. Da muss man in der main.bmx ein NoDebug unter das SuperStrict stellen (das nimmt der Hauptdatei aber die Debugfunktionalitäten):
BlitzMax: [AUSKLAPPEN]

'main.bmx (Debugmodus)
SuperStrict
NoDebug
Import "imp.bmx"
Global x:Int=1337
Print y

mfg Thunder

Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

	Tritium	Mo, Apr 18, 2011 18:25 Antworten mit Zitat
Mh, das ist allerdings schade - Debugging ist ja leider schon wichtig Bedeutet das denn, dass das Debugging dann nur in der main.bmx deaktiviert ist und in den anderen Dateien noch funktioniert? Oder muss man dann auf Debugging komplett verzichten?

Tritium

Mo, Apr 18, 2011 18:25
Antworten mit Zitat

Mh, das ist allerdings schade - Debugging ist ja leider schon wichtig Confused

Bedeutet das denn, dass das Debugging dann nur in der main.bmx deaktiviert ist und in den anderen Dateien noch funktioniert? Oder muss man dann auf Debugging komplett verzichten?

	Thunder	Mo, Apr 18, 2011 22:00 Antworten mit Zitat
Mit NoDebug wäre Debugging nur in der Maindatei deaktiviert. Ich habe leider keinen Weg gefunden, das ohne Debug hinzubekommen, weil sich BlitzMax im Debugmodus generell anders verhält. Aus einem, mir völlig unbekannten Grund, wird nämlich x im Debugmodus in der Assemblerdatei doppelt deklariert (einmal als extrn und einmal als public). Man könnte auch bei jeder Kompilation die extrn-Deklaration entfernen, aber das ist doch sehr unhandlich. mfg Thunder
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Thunder

Mo, Apr 18, 2011 22:00
Antworten mit Zitat

Mit NoDebug wäre Debugging nur in der Maindatei deaktiviert. Ich habe leider keinen Weg gefunden, das ohne Debug hinzubekommen, weil sich BlitzMax im Debugmodus generell anders verhält. Aus einem, mir völlig unbekannten Grund, wird nämlich x im Debugmodus in der Assemblerdatei doppelt deklariert (einmal als extrn und einmal als public).
Man könnte auch bei jeder Kompilation die extrn-Deklaration entfernen, aber das ist doch sehr unhandlich.

mfg Thunder

Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

	Tritium	Di, Apr 19, 2011 19:35 Antworten mit Zitat
OK, Danke!

Tritium

Di, Apr 19, 2011 19:35
Antworten mit Zitat

OK, Danke!

Übersicht

BlitzMax, BlitzMax NG

Beginners-Corner

Nach Oben

BlitzBasic Portal

Include, Globale Variablen & Private

Betreff: Include, Globale Variablen & Private