amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > StormC4: globale Variablen debuggen [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

06.03.2003, 22:35 Uhr

Uwe
Posts: 74
Nutzer
Hallo,

beim Debuggen von C und C++ Programmen mit StormC V4
werden die globalen Variablen nicht angezeigt.
Die entsprechende Liste ist leer.
Die lokalen Variablen werden dagegen angezeigt.

Ich habe die neueste Version (Patch von H&P) installiert.

Was ist da los?

MfG Uwe

[ - Antworten - Zitieren - Direktlink - ]

11.03.2003, 01:06 Uhr

Tessien
Posts: 55
Nutzer
Moin Uwe,

da sich hier in den letzten Tagen niemand erbarmt hat, übernehme ich es denn doch:

Es geht nicht. Kurze Antwort, große Tragweite. Globale Variablen werden gar nicht (PPC) oder mit Zufallsinhalten (68k) angezeigt. Oder war's andersrum? Wie auch immer, in jedem Fall geht es nicht, was den Nutzen des Debuggers doch arg schmälert. Besser als printf-Debuggen ist es immernoch, aber nur noch knapp. Im Zweifelsfalle eine lokale Variable vor Ort erfinden und die globale Var hineinkopieren. Und unbedingt sicherstellen, daß der Compiler diese Zuweisung nicht gleich wieder rausoptimiert, also Optimierungslevel runterschrauben.

Bye, Thomas
--
Thomas Schulze - programmer at Dreamworlds Development - http://www.dreamworlds.de

[ - Antworten - Zitieren - Direktlink - ]

11.03.2003, 13:37 Uhr

Solar
Posts: 3680
Nutzer
Ich weiß zwar nicht, was los ist, aber ich kann nur raten, von globalen Variablen wo immer möglich komplett die Finger zu lassen. Aus einer ganzen Reihe von Gründen, u.a. Seiteneffekte, Thread-Safety - und Problemen mit Debuggern. ;-)

[ - Antworten - Zitieren - Direktlink - ]

11.03.2003, 14:45 Uhr

Tessien
Posts: 55
Nutzer
@Solar:

Meinungsfrage... ich halte sie in begrenztem Rahmen eher für nützlich als für schädlich. Zuviele davon sind allerdings ein Zeichen für schlechtes Programmdesign. Bei mir sind z.B. die Hardware-Interface-Klassen immer global. Multithread-Sicherheit ist für Spiele sowieso unnötig, da ein Spiel wohl kaum im gleichen Speicherbereich zweimal läuft. Wenn es nur zweimal gestartet wird, bekommt es eh zwei unabhängige Speicherbereiche und das Problem ist keines mehr.

So sehe ich das zumindest als Spieleprogrammierer. Du wirst darüber vermutlich eine andere Meinung haben.

Bye, Thomas
--
Thomas Schulze - programmer at Dreamworlds Development - http://www.dreamworlds.de

[ - Antworten - Zitieren - Direktlink - ]

11.03.2003, 15:22 Uhr

Solar
Posts: 3680
Nutzer
Es geht bei Thread-Sicherheit nicht darum, ob ein Spiel zweimal gestartet wird. Es geht darum, ob mehr als ein Kontrollfluß (Thread) im gleichen Addressraum werkelt.

Wenn z.B. in einem Echtzeit-Strategiespiel der Artificial Opponent einen eigenen Thread spendiert bekommt und die grafische Oberfläche den zweiten, schon hast Du ein potentielles Problem.

Natürlich ist sowas immer Ansichtssache; wer vorsichtig programmiert, braucht niemals Probleme mit globalen Variablen bekommen. Das gleiche gilt aber auch für die Verwendung von "goto"... ;-)

[ - Antworten - Zitieren - Direktlink - ]

11.03.2003, 20:52 Uhr

mrbbc
Posts: 101
Nutzer
Apropos globale Variabelen Für und Wider...

Grundsätzlich kann man damit ein Programm nicht unwesentlich optimieren... Alle lokalen Variabelen, vorallem Strings, werden am Funktionsanfang alloziert, und beim return wieder freigegeben. Das kostet ziemlich Zeit - ausser, die Funktion wird vom Compiler wegoptimiert, dann wird nur das Programm größer...

Aber wie gesagt sollte man sich wirklich bewusst sein, ob man eine Variabele global deklariert, wozu einem C eigentlich auch mehr oder weniger zwingt. - Nicht nur wegen Threadsicherheit, sondern auch zwecks Rekursion.

Alles hat zwei Seiten.

--
it obvisiously seems to have been hard to write

[ - Antworten - Zitieren - Direktlink - ]

16.03.2003, 18:15 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von mrbbc:
Apropos globale Variabelen Für und Wider...

Grundsätzlich kann man damit ein Programm nicht unwesentlich optimieren... Alle lokalen Variabelen, vorallem Strings, werden am Funktionsanfang alloziert, und beim return wieder freigegeben.

Bist Du Dir sicher, daß Du hier nicht Variablen mit Konstanten verwechselst? Konstanten sind die Dinger, wie z.B. Strings mit vorderfiniertem Inhalt, die durchaus an eine globale Stelle gehören und dort mit symbolischen Namen versehen werden dürfen. Mit Variablen, deren Inhalt zur Compile-Zeit nicht bekannt ist, haben die aber nichts zu tun.
Das Alloziieren und Freigeben von Variablen besteht i.A. aus dem Addieren/Subtrahieren einer Konstanten Zahl (dem benötigtem Speicher) zum Stackpointer. Einige CPUs bieten sogar kombinierte Befehle für Unterprogrammaufrufe und lokales Variablenmanagment.
Zitat:
Aber wie gesagt sollte man sich wirklich bewusst sein, ob man eine Variabele global deklariert, wozu einem C eigentlich auch mehr oder weniger zwingt. - Nicht nur wegen Threadsicherheit, sondern auch zwecks Rekursion.

C zwingt einen überhaupt nicht zu solchen Vorgehensweisen. Und wo Du schon die Rekursion ansprichst: Schon die Möglichkeit eines einzelnen verschalteten Aufrufs verbietet globale Variablen.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

16.03.2003, 21:09 Uhr

mrbbc
Posts: 101
Nutzer
Zitat:
Original von Holger:
Zitat:
Original von mrbbc:
Apropos globale Variabelen Für und Wider...

Grundsätzlich kann man damit ein Programm nicht unwesentlich optimieren... Alle lokalen Variabelen, vorallem Strings, werden am Funktionsanfang alloziert, und beim return wieder freigegeben.

Bist Du Dir sicher, daß Du hier nicht Variablen mit Konstanten verwechselst?

Ja.

Zitat:
Das Allozieren und Freigeben von Variablen besteht i.A. aus dem Addieren/Subtrahieren einer Konstanten Zahl (dem benötigtem Speicher) zum Stackpointer.

Eine globale Variabele hat einfach einen festen Platz im Speicher.

Größere Arrays werden ausserdem sicher nicht auf dem Stack angelegt.

Denk' ausserdem nochmal den Satz durch, zu was C mehr oder weniger zwingt, das hast du falsch interpretiert...

--
it obvisiously seems to have been hard to write

[ - Antworten - Zitieren - Direktlink - ]

16.03.2003, 21:18 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von mrbbc:
Eine globale Variabele hat einfach einen festen Platz im Speicher.

Die i.A. genauso über ein Adressregister angesprochen wird, wie eine lokale über den Stackpointer. Ob das Register a4 oder a7 ist, spielt für die Ausführungszeit keine Rolle.
Zitat:
Größere Arrays werden ausserdem sicher nicht auf dem Stack angelegt.
Doch.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

17.03.2003, 05:58 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von mrbbc:
Eine globale Variabele hat einfach einen festen Platz im Speicher.

Größere Arrays werden ausserdem sicher nicht auf dem Stack angelegt.


Der "feste Platz" ist eben das Problem beim Multithreading (und bei Rekursion). Der Performance-Gewinn durch globale Variablen wird m.E. überschätzt; meiner Meinung nach wiegt er die Multithread-Probleme, schlechtere Datenlokalität und schwerer verständliche Programmlogik nicht auf.

Ansichtssache, ich weiß, aber ich habe da die Mehrzahl der Style Guides im Rücken... ;-)

[ - Antworten - Zitieren - Direktlink - ]

17.03.2003, 13:09 Uhr

mrbbc
Posts: 101
Nutzer
Zitat:
Original von Solar:
Der "feste Platz" ist eben das Problem beim Multithreading (und bei Rekursion). Der Performance-Gewinn durch globale Variablen wird m.E. überschätzt; meiner Meinung nach wiegt er die Multithread-Probleme,

schlechtere Datenlokalität


*bg*

Zitat:
und schwerer verständliche Programmlogik nicht auf.

Könnte nicht sagen, dass die Programmlogik schwerer verständlich wird. Das passiert nur durchs Multithreading selbst.

Wie gesagt sollte man g.V. sehr sparsam einsetzen, damit man nicht den Überblick verliert; ausserdem sollte man sie natürlich auch kennzeichnen, damit man im Quelltext gleich sieht und kapiert, dass es globale sind.

Wenn z.B. mehrere Threads eben nur die globale Variabele lesen, bzw. nur ein Thread sie schreibt/verwendet, ist es ja kein Problem.

Auch bei Rekursion braucht man manchmal sogar eine globale Variabele, weil die Funktion bei der Selbstberufigung schließlich die Inhalte der lokalen Variabelen "vergisst".

Das mit dem Allozieren ist aber kein kleines Performanceproblem. So ein "malloc()" braucht schon einige Zeit bis die Speicherverwaltung alles zusammengesucht hat; besonders krass ist global-alloc unter Windows, d.h. wenn man globalen Speicher anfordert - Speicher, der von allen Programmen benutzt und freigegeben werden kann.

Andererseits wird es wohl sicher nicht vorkommen, dass man in einem OpenGL-Spiel Funktionen hat, die hundert mal in der Sekunde Speicher allozieren... Wenn man's bräuchte, dann umgeht man das natürlich.

--
it obvisiously seems to have been hard to write

[ - Antworten - Zitieren - Direktlink - ]

17.03.2003, 15:03 Uhr

Solar
Posts: 3680
Nutzer
Zitat:
Original von mrbbc:
Könnte nicht sagen, dass die Programmlogik schwerer verständlich wird. Das passiert nur durchs Multithreading selbst.


Globale Variablen sind grundsätzlich "out of scope" - damit meine ich, Du findest sie weder in der Argumentliste, noch im Deklarationsteil, noch (bei C++) in der Klassendeklaration. Bei der "Vorliebe" vieler Programmierer für Code-Kommentare ist das schon ein Problem.

Multithreading macht die Sache natürlich komplizierter, dafür kann man hier auch eine Menge rausholen. Multithreading mit globalen Variablen, wie schon angemerkt, ist zu 90% ein Bug.

Zitat:
Wie gesagt sollte man g.V. sehr sparsam einsetzen, damit man nicht den Überblick verliert; ausserdem sollte man sie natürlich auch kennzeichnen, damit man im Quelltext gleich sieht und kapiert, dass es globale sind.

Das Problem ist dabei, daß es noch schwerer ist, "echten" Programmierern ordentliche Benennung und Namensgebung einzubläuen, als globale Variablen insgesamt zu ächten. Vor allem beim Code Review wird's einfacher.

Zitat:
Wenn z.B. mehrere Threads eben nur die globale Variabele lesen, bzw. nur ein Thread sie schreibt/verwendet, ist es ja kein Problem.

Holla! Ich hoffe, Dein schreibender Thread benutzt sowas wie Transaktionslogik bzw. atomic commit. (Sprich, Du hast den Fall bedacht, daß zwischen Eintreten einer Bedingung und der Aktualisierung der globalen Variablen ein anderer Thread die Variable auslesen könnte...)

Zitat:
Auch bei Rekursion braucht man manchmal sogar eine globale Variabele, weil die Funktion bei der Selbstberufigung schließlich die Inhalte der lokalen Variabelen "vergisst".

Tip: "static".

Zitat:
Das mit dem Allozieren ist aber kein kleines Performanceproblem. So ein "malloc()" braucht schon einige Zeit bis die Speicherverwaltung alles zusammengesucht hat...

Für den Stack braucht's kein malloc(), den brauchst Du nur auf dem Heap.

Zitat:
...besonders krass ist global-alloc unter Windows, d.h. wenn man globalen Speicher anfordert - Speicher, der von allen Programmen benutzt und freigegeben werden kann.

Klingt das nach einem Argument gegen globalen Krams? ;-)

[ - Antworten - Zitieren - Direktlink - ]

17.03.2003, 18:47 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von mrbbc:
Auch bei Rekursion braucht man manchmal sogar eine globale Variabele, weil die Funktion bei der Selbstberufigung schließlich die Inhalte der lokalen Variabelen "vergisst".

Keine Funktion vergißt die Inhalte von lokalen Variablen. Wenn Du meinst, daß in einem erneuten Aufruf ein eigener Scope existiert und nach dem Aufruf der alte wiederhergestellt wird, daß ist der Sinn und Zweck von lokalen Variablen.
Wenn Du modifizierte Werte übergeben willst, dann benutze Parameter und Rückgabewerte, dafür sind sie da.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > StormC4: globale Variablen debuggen [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.