Suche eine Programmiersprache!

[Sovok]

Power Off schrieb:

Sovok schrieb:

kann vc++ auch

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsdebug/html/vchowusingeditcontinue.asp

Das ist NICHT dasselbe!

und warum ned?

[Power Off]

Sovok schrieb:

und warum ned?

Ganz einfach: Weil ich für Edit & Continue das Programm ändern muß, aber bei der SAS/C-Methode (bzw. GDB-Methode) nicht.

[Sovok]

und was heisst das jetzt? bin ich deswegen verstralt?
praktisch macht das doch garkeinen unterschied

du drückst auf pause, wechselst im callstack in deinen code, änderst die nächste zeile und gut is

[Power Off]

Sovok schrieb:

und was heisst das jetzt? bin ich deswegen verstralt?
praktisch macht das doch garkeinen unterschied

du drückst auf pause, wechselst im callstack in deinen code, änderst die nächste zeile und gut is

Trotzdem ... ich hätte lieber ein Command-Fenster!

Außerdem würde es mir schwer stinken, hinterher die ganzen Änderungen wieder rauszunehmen!

[Talla]

Power Off schrieb:

Sovok schrieb:

was meinst du mit "seinen eigenen Programmcode aufrufen"

Na z.B.

print mycoolfunc(123.4,5)

peng, Ausgabe kommt!
oder

openMyWindow( 100, 100, 200, 200 );

schwupps, ist es da!

Aus dem Debugger! Während das Programm gedebuggt wird (aber gestoppt ist).
D.h. der Debugger führt den Code aus, den ich eingebe, auch wenn er
Referenzen auf das gedebuggte Programm enthält.

Gut, 'ne? GDB kann das auch; seit ich das weiß, gefällt mir der GDB wieder viel besser.
(jetzt müßte er nur noch multithread-Programme debuggen können ...
vielleicht geht's ja jetzt mit dem 2.6er Kernel, aber früher ging's nicht)

Okay, beim klassischen C++ weiß ichs nicht genau, aber zumindest der CLR Debugger kann genau das bei C++.Net, Kannst alle Funktionen aufrufen die im Skope liegen. Funktioniert auch in C#

[Hutzli_]

groovemaster schrieb:

Sehe ich nicht so. Ich finde, der Debugger beim VC++ ist ziemlich genial. Wobei ich nur gdb noch kenne, was im Vergleich dazu aber einfach nicht mithalten kann. Zumindest hab ich noch kein vernünftiges Frontend dafür gesehen. Nenn mir doch mal ein paar aussergewöhnliche Debugger, die den MS Debugger zur "Standardware" verkommen lassen.

Also ich bin durchaus selber ein Fan vom VisualStudio-Debugger, und finde nicht wirklich das er Standardware ist. Aber trotzdem gibt es schon noch einiges zu verbessern. Vor allem beim Thread-Support ist noch reichlich Luft, wenn man ihn mit dem (für Unix/Linux erhältlichen) Totalview von Etnus vergleicht. Ich gebe zu, in Sachen GUI-Entwicklung gibt es IMHO (wie bei vielen kommerziellen Unix-Anwendungen) für Etnus noch vieles zu lernen, aber die Thread-Unterstützung ist klasse. Threads können z.B. gruppiert werden und je nach Wunsch kann man mehrere Threads dann z.B. auch gemeinsam steppen lassen. Das ist eine großartige Hilfe, um Race-Conditions zu jagen.

Generell wünsche ich mir von den Debuggern eine bessere Template-Unterstützung, es wäre durchaus möglich, die Templates beim Debuggen optional mit aufgelösten Parametern anzuzeigen, das würde manchmal den Überblick vereinfachen, aber das hab ich noch nirgends gefunden. (Nicht das man die Typen nicht rausbekommt, geht mir nur um den Konfort.)

[groovemaster]

kingruedi schrieb:

Aber nennt mal bitte ein Killer Feature des VC++ Debuggers

Was ist für dich denn ein Killer Feature?
Oh, ich hab eines. Wie du vielleicht weisst, benutzt WinAPI für Fehlerwerte HRESULT. Wenn du so einen also hast, steht im Überwachungsfenster nicht irgendein nichtssagender Wert, sondern Klartext. Das nenn ich doch mal Killer Feature. So bleibt dir ständiges Suchen in der winerror.h erspart.

Zudem muss ich gestehen, dass ich bei einem Debugger keine Killer Features brauche. Man arbeitet damit idR wirklich nur in Extremfällen. Und der VC++ Debugger bietet (fast) alles, was man zum vernünftigen Arbeiten braucht:
- automatische Variablenüberwachung
- lokale Variablenüberwachung
- benutzerdefinierte Überwachung von Ausdrücken
- Überwachung von Prozessen, Threads und Modulen
- Call Stack
- Breakpoints
- x86 Register, FPU, MMX, SSE, 3DNOW, Flags
- Konsole
- umschalten zwischen Code und Assembly
- und noch einiges mehr, was ich noch nicht mal ansatzweise getestet habe

Und zu Power Off's Aussagen möchte ich nichts weiter sagen, da er offensichtlich nicht ganz auf dem Laufenden ist. Zudem bietet VC++ ebenfalls Code- und Projekt-Browsing, das ist aber nicht Debugger spezifisch. Und was das Ausführen von eigenem Code betrifft, da fehlt mir momentan noch das Verständnis, wozu man das brauchen könnte. Immerhin will ich den Code debuggen, den ich auch real habe und nicht irgendwelche Sachen zwischendurch ausführen lassen. Variablen und Speicher kann man ja auch so problemlos bearbeiten.

Hutzli_ schrieb:

Aber trotzdem gibt es schon noch einiges zu verbessern.

Dagegen ist ja auch nichts zu sagen. Nur kann ich mit dem VC++ Debugger momentan wunderbar leben, mit GDB nicht, weil ich dafür bisher einfach noch kein vernünftiges Frontend gefunden habe.

[rüdiger]

@groovemaster
Naja, dass kann wohl jeder vernünftige Debugger. Also sagen wir ein Killer Feature gibt es nicht, es geht mehr um Sympathien

Und was das Ausführen von eigenem Code betrifft, da fehlt mir momentan noch das Verständnis, wozu man das brauchen könnte. Immerhin will ich den Code debuggen, den ich auch real habe und nicht irgendwelche Sachen zwischendurch ausführen lassen. Variablen und Speicher kann man ja auch so problemlos bearbeiten.

Das hilft einem einfach bei der Fehleranalyse. Zum einen kann man so Funktionen mit Seiten-Effekten besser testen, weil man die Programmsituation ja vorgeben kann. Zum anderen kann man so direkt untersuchungen durchführen, ohne das man sich einen Testcode schreiben muss.

[groovemaster]

kingruedi schrieb:

Naja, dass kann wohl jeder vernünftige Debugger.

Mit dem GDB hab ich sowas zB nicht mal ansatzweise hinbekommen, aber du kannst mich gerne eines Besseren belehren und mir dafür ein vernünftiges Frontend geben. Es geht ja nicht nur um die einzelnen Features selbst, sondern auch darum, wie man diese handeln kann.

kingruedi schrieb:

Das hilft einem einfach bei der Fehleranalyse. Zum einen kann man so Funktionen mit Seiten-Effekten besser testen, weil man die Programmsituation ja vorgeben kann. Zum anderen kann man so direkt untersuchungen durchführen, ohne das man sich einen Testcode schreiben muss.

Nunja, ich muss gestehen, dass ich für sowas bisher gut ohne das Ausführen von benutzerdefiniertem Code ausgekommen bin. Entweder man ändert sich entsprechende Zustände (Daten) oder setzt den IP an die gewünschte Stelle.
Ich finde auch nicht, das sowas zu den Kernfeatures eines Debuggers gehört. Wenn man sich zB mal einen puren, nicht sprachspezifischen Debugger anschaut, zB Olly, wie will man denn dort sowas implementieren? Bzw anhand welcher Kriterien will man denn sowas implementieren? Einfach die Syntax einer Sprache adaptieren oder einfach eine neue erfinden? Oder doch nur Assembler? Wäre irgendwie sinnlos, oder? Und wie sieht es dann mit dem Funktionsumfang aus?
Zudem ist sowas bei Compilersprachen recht aufwändig, da sollen sich die Entwickler lieber darauf konzentrieren, die wirklich wichtigen Features weiter zu verbessern. Ich sehe bisher zumindest noch keinen grossen Nachteil, wenn ein Debugger sowas nicht anbietet. Kann aber auch daran liegen, dass mir einfach die Erfahrung damit fehlt.

[rüdiger]

Das ist eben ein gutes Zusatzfeature. So etwas unterscheidet eben gute Debugger von gewöhnlichen Debuggern. Deswegen hab ich ja auch beim VC++ Debugger nach einem Killerfeature gefragt

Gute Frontends für den GDB sind Insight, KDbg und DDD.

Ansonsten bieten die GCC kompatiblen IDEs idr. auch GDB Support an. zB GNU/Emacs

[groovemaster]

Oh, ich hätte vielleicht dazu schreiben sollen, dass ich was für Windows suche.

[Power Off]

groovemaster schrieb:

Wenn man sich zB mal einen puren, nicht sprachspezifischen Debugger anschaut, zB Olly, wie will man denn dort sowas implementieren?

Ein Sprachunabhängiger Debugger liest einfach die Debug-Segmente aus dem ausführbaren Programm aus. Bei zeilenweisen Debug-Informationen steht dann z.B. der Quelltext der Programmzeile, die den Fehler erzeugt hat, mit im Debug-Segment (bzw. ein Verweise auf die Quelldatei und eine Zeilennumer).

Symbolinformationen stehen auch im Debug-Segment (manchmal auch im Code-/Datensegment). D.h. der Debugger kann dann die Adressen von globalen Variablen und Funktionen ermitteln (nur, die keine static linkage haben).

Das kann durchaus reichen, um einen halbwegs vernünftigen Debugger auf die Beine zu stellen. Man kommt halt dann nicht an lokale Variable dran, außer man vergleicht manuell den Source und den jeweiligen Stackframe / Registersatz. Aber es lassen sich z.B. ein Call-Stack anlegen und auch globale Variable auslesen (über einen Memory Dump).

Manche Debug-Formaten können auch weitergehende Debuginformationen sprachunabhängig codieren.

Oder ein Debugger bringt Syntax Analyzer für die gängigsten Sprachen mit und parst die in der Debug-Information angegebene Quelldatei.

(so oder so ähnlich dürften andere Debugger wie GDB oder der MS Debugger auch funktionieren)

[groovemaster]

Erstmal ein teilweises nö. Eine Executable muss keine Debug Infos enthalten, zudem sind diese nicht standardisiert. Und zweitens, was hat das mit der Implementation eines Interpreters zu tun?

[Power Off]

groovemaster schrieb:

Erstmal ein teilweises nö. Eine Executable muss keine Debug Infos enthalten, zudem sind diese nicht standardisiert. Und zweitens, was hat das mit der Implementation eines Interpreters zu tun?

Ein Syntax Analyzer ist kein Interpreter. Er zerlegt den Quelltext in eine interne Form, meist einen Syntax-Baum.

Wenn im Executable keine Debug-Infos vorhanden sind, können alle Debugger nur noch den Assembler-Code von Code-Segment bzw. die Rohdaten in Datensegmenten anzeigen. Benutzer von IDEs merken das meist nicht, weil sie ihre Projekte immer als Debug-Projekte compilieren.

Die Debug-Informationen sind sehr wohl standardisiert. Z.B. Microsoft VC++ verwendet ein von COFF abgeleitetes Format, kann aber auch andere Formate erzeugen.

[groovemaster]

Power Off schrieb:

Ein Syntax Analyzer ist kein Interpreter.

Ich dachte es geht darum, benutzerdefinierten Code ausführen zu lassen? Davon war zumindest die Rede. Einen "Syntax Analyzer" besitzt der VC++ Debugger zB auch.

Power Off schrieb:

Die Debug-Informationen sind sehr wohl standardisiert. Z.B. Microsoft VC++ verwendet ein von COFF abgeleitetes Format

Was aber nicht COFF kompatibel ist, afaik. Ergo, es gibt kein einheitliches Debug Format also kein einheitlicher Standard. Letztendlich macht das jeder Compiler wie er lustig ist, auch wenn man natürlich ein definiertes Format verwenden kann, wie zB COFF.

[kartoffelsack]

hab hier zwei Sachen gelesen, die der VC++ haben soll:

Memory-Breakpoint: Wo, wie? Unterbricht er, wenn sich der Wert an einer Adresse ändert? Wie mach man das???

Profiler: Wie schalt ich bei VC++ 7.1 (professional) den Profiler an? Weiß nur, dass der 6er einen hatte, hab jahrelang mit dem BCB gearbeitet und mich gefreut, als wir auf VC++7.1 umgestiegen sind. Jetzt find ich aber nirgends den Profiler.

[->Sovok<-]

kartoffelsack schrieb:

hab hier zwei Sachen gelesen, die der VC++ haben soll:

Memory-Breakpoint: Wo, wie? Unterbricht er, wenn sich der Wert an einer Adresse ändert? Wie mach man das???

Profiler: Wie schalt ich bei VC++ 7.1 (professional) den Profiler an? Weiß nur, dass der 6er einen hatte, hab jahrelang mit dem BCB gearbeitet und mich gefreut, als wir auf VC++7.1 umgestiegen sind. Jetzt find ich aber nirgends den Profiler.

kann ich dir beides nur beim 6er erklärn

[kartoffelsack]

Dann erklär mir mal memory-Breakpoint beim 6er. Soviel anders wirds beim 7.1er schon nicht sein. Ganz schön traurig, dass ich nicht weiß, wie man das macht

[musicman]

Im VC 6 mit Strg+B den Dialog für Breakpoints öffnen und bei Data eine Expression wie DW(0xabcdefg) eingeben, ich glaub mal so war die Syntax für ein DWORD an der enstprechenden Adresse.

[Sovok]

so wie musicman es beschrieben hat

außer, dass ich immer nur ne adresse oben reinschreib und dann unten bei number of elements die anzahl von bytes die ich überwachen will

im fall von musicmans beispiel also 4 unten rein weil unsigned long ( DWORD ) 4 bytes hat

du kannst bei expression aber auch sowas reinschreiben wie

( ( ( ( unsigned long ) 0xabcdefg ) == 100 ) && ( ( ( int ) 0xdfghjk ) == 50 ) )

dann hält er an wenn der ulong an adresse 0xabcdefg den wert 100 und der int an adresse 0xdfghjk den wert 50 hat

das is besonders im debugmodus geil, weil die variablen im debugmodus immer an den gleichen adressen stehn
d.h. du kannst einen breakpunkt drauf setzen ohne dass dich dergültigkeitsbereich interessieren brauch ( z.b. bei membervariablen interessant )