Suche eine Programmiersprache!

groovemaster

LUZA schrieb:

weshalb versaut man sich den c++-stil, wenn man erst eine prozeduale sprache lernt und dann eine objektorientierte?

Das frage ich mich auch manchmal. Wieso wird sowas immer gelich generalisiert?

LUZA schrieb:

ich habe mit diesem lego-zeugs angefangen, dann nqc ( fürs lego, aber c-syntax)
und dann c++ gelernt und ich muss ehrlich sagen, ich halte meinen c++-stil für sehr gut, und die kentnisse in c helfen eher...

Hab zwar nicht mit diesem Lego Zeugs angefangen, aber nach Pascal auch C gelernt, und später C++. Ob mein Stil jetzt versaut ist, sollen andere beurteilen. Aber die C Kenntnisse helfen enorm. Und an seinem Stil kann man immer arbeiten.

@Winkywankel
Dennoch, wenn man sich die Frage stellt, ob man eher C oder C++ lernen soll, dann fang sofort mit C++ an. Die Grundlagen sind sowieso gleich (bis auf sehr wenige Details). Darüber hinaus bietet C++ aber noch einiges mehr.

Power Off schrieb:

Das mit Faktor 5-10 kannste selber nachprüfen, in dem Du mal Code vergleichst, den Du in handoptimiertem Assembler selber geschrieben hast (die Prozessorhandbücher warten schon auf Dich, um Dir zu zeigen, wieviel Prozent des Befehlsatzes der Compiler benutzt).

Schön wenn man sich seinen Code so zusammenbasteln kann, ich vertraue auch nur synthetischen Benchmarks. Nur mit realen Anwendungen hat das nichts zu tun. Ich bin manchmal selbst erstaunt, wie wenig Unterschied es zwischen einem Debug und Release Build, bzgl. der Ausführungsgeschwindigkeit, gibt.

Power Off schrieb:

a ja, im Prinzip sind templates ja gar nix anderes als Makros (aus der Sicht des Compilers).

Nö, ein Compiler kennt nicht mal Makros. Genauso wenig, wie ein Präprozessor Templates kennt.

O'Rakl schrieb:

C ist für den Anfang ganz gut, man muß es halt können. Wenn man C oder besser noch C++ kann,
ist es leicht, andere Sprachen zu lernen, denn gerade C++ ist derart
kompliziert, daß es einem den Atem verschlägt, wenn man sieht, wie man
Programme, die in C++ Bildschirmseiten füllen (gerade Listenverarbeitung,
Komprehension oder auch Funktionen als Argumente) mit Python in ein paar
Zeilen hinschreiben kann.

Ach nö, nicht schon wieder. Geh zurück in deinen Troll Thread.

Power Off schrieb:

Der Microsoft Debugger ist mehr oder weniger Standardware

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.

Power Off

groovemaster schrieb:

Nenn mir doch mal ein paar aussergewöhnliche Debugger, die den MS Debugger zur "Standardware" verkommen lassen.

Der beste Debugger, den ich bisher gesehen habe, war der SAS/C Debugger für AmigaOS. Damit konnte man (genau wie bei gdb) seinen eigenen Programmcode aufrufen, wenn das Programm gestoppt war. Hatte also einen Interpreter für C-Ausdrücke (später auch C++). SAS/C war auch in anderer Hinsicht genial: Man konnte aus seinem Code eine komplette Hypertext-(AmigaGuide-)Referenz erstellen und mit einem AmigaGuide-Browser einfach durch sein ganzes Projekt browsen, durch Doku, Include-Files, alles. Und die Querverweise sind vollautomatisch erstellt worden. Dagegen ist VC++ wirklich der letzte Schrott. Und die Optimierungen hättest Du erstmal sehen sollen. Und das lustigste war, daß zum Schluß der Compiler nur noch von einem Kerl weiterentwickelt wurde. Leider kam dann auch irgendwann das Aus. Das war echt schade, ich hätte mir gewünscht, ähnlich gute Entwicklungsumgebungen auch mal für Windows oder Linux zu sehen zu kriegen, aber nix, bis jetzt.

Ach ja, und im Gegensatz zum Watcom oder VC++ Debugger ist der SAS/C Debugger beim Debuggen von Multithread-Anwendungen niemals abgestürzt, auch wenn gerade ein Nachrichtenaustausch mit der Oberfläche stattfand. Das war allerdings der Verdienst von AmigaOS, das echte MessageQueues benutzt hat (im Gegensatz zu Windows, wo meist direkte Callback-Aufrufe gemacht werden).

Für mich ist eine perfekte Computerwelt zusammengebrochen, als ich zum ersten Mal mit MS-DOS und MS-Windows arbeiten mußte. Was ein Rotz!

Zu Hause benutze ich mittlerweile nur noch Linux, aber da wird halt auch nur mit Wasser gekocht, leider, auch wenn's da schon mehr gute Sachen gibt. Und viele ehemalige Amiga-Programmierer entwickeln schon seit vielen Jahren für Linux, ohne die wäre bestimmt etliches gar nicht erst zustandegekommen.

Sovok

was meinst du mit "seinen eigenen Programmcode aufrufen"
für die doku gibts http://www.stack.nl/~dimitri/doxygen/ das brauch man nich in vc++

fürs browsen im code gibts die browseinformationen die richtig gut sind wenn man damit umgehn kann und mit visual assist x wird das ganze nochmal deutlich verbessert

Power Off

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)

Sovok

kann vc++ auch

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

Power Off merkst du nicht, dass du dich mit deinem Halbwissen lächerlich machst?

Ich streite nicht ab, dass du schon viele Jahre programmiert hast, aber wenn es um heutiges C++ geht scheinst du ernsthaft auf der Strecke geblieben zu sein.

Power Off

Sovok schrieb:

kann vc++ auch

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

Das ist NICHT dasselbe!

Power Off

... schrieb:

Power Off merkst du nicht, dass du dich mit deinem Halbwissen lächerlich machst?

Ich streite nicht ab, dass du schon viele Jahre programmiert hast, aber wenn es um heutiges C++ geht scheinst du ernsthaft auf der Strecke geblieben zu sein.

Ich bin zwar nicht ganz auf dem Laufenden, was C++ betrifft, das heißt aber noch lange nicht, daß ich über "Halbwissen" verfüge!

Bin halt ein Dinosaurier!

rüdiger

Kann der VC++ Debugger auch Remote Debugging?

Aber nennt mal bitte ein Killer Feature des VC++ Debuggers, würde mich interessieren, weil der ja so hoch gelobt wurde.

@Power Off
http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC27
http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC28

ist vielleicht nicht sonderlich komfortabel, aber möglich

Power Off

kingruedi schrieb:

@Power Off
http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC27
http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC28

ist vielleicht nicht sonderlich komfortabel, aber möglich

Ja, theoretisch schon. Aber das gilt wohl nur für Betriebssysteme, die einen "ordentlichen" Kernel haben.

Bei Linux gibt es vor Kernel 2.6 das Problem, daß der Kernel z.B. im Core-Dump keine Threadinformation schreibt, weil jeder Thread ein eigener Prozess ist, und die Prozesse separat abkacken.

Bei 2.6 gibt es das Problem, daß der GDB die neuen Core-Files nicht lesen kann, oder so.

Vielleicht irre ich mich ja auch.

Ach so, ich beziehe mich natürlich auf das Post-Mortem Debugging, also nachdem das Programm abgestürzt ist.

Es gibt im Live-Betrieb noch das Problem, daß der GDB die Thread-Informationen nicht lesen kann, und daß er auf Signale seltsam reagiert.

Vielleicht habe ich schon mit SuSE 9.3 einen neuen GDB der mit dem 2.6er Kernel harmoniert. Muß ich mal ausprobieren. Hab 9.3 noch nicht so lange installiert.

Trotzdem danke!

Sovok

kingruedi schrieb:

Kann der VC++ Debugger auch Remote Debugging?

Aber nennt mal bitte ein Killer Feature des VC++ Debuggers, würde mich interessieren, weil der ja so hoch gelobt wurde.

@Power Off
http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC27
http://sources.redhat.com/gdb/current/onlinedocs/gdb_5.html#SEC28

ist vielleicht nicht sonderlich komfortabel, aber möglich

erstellen->remote verbindung des debuggers
der vc debugger hat viel was ich bei den gängigen anderen debuggern vermisse
in erster linie gehts da um komfort und geschwindigkeit des debuggings aber hab ich alles vorher schon genannt

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#

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.