Suche eine Programmiersprache!

Power Off

Sovok schrieb:

beim gdb hat mich vorallem das frontend gestört... saulangsam und total unintuitiv

Da haste voll recht, die hätten mittlerweile schon längst wenigstens eine ncurses-Version oder eine GUI Version machen können. Aber das kommt ja vielleicht irgendwann noch.

Die Menüsteuerung vom GDB find ich auch zum kotzen.

Power Off schrieb:

Talla schrieb:

Dir ist klar das der 2002er C++ Compiler von Microsoft nur nen leicht aufgebohrter 6er ist - und beide sind an sich net wirklich gut. Der 2003er dagegen ist wieder richtig gut, und den optimizing Compiler kannst dir sogar kostenlos von Microsoft besorgen

Der 2002er und der 2003er sind fast identisch. Hab schon mit beiden gearbeitet (und auch mit dem 6er).

Der 2002er hat die Version 7.0 und der 2003er die Version 7.1, aber sonst ...

Doch, der 2003er ist mehr standardkonform als der 2002er.

Naja, für den der keine managed Programme schreibt und kein .NET braucht hat der 7.0 nichts gegenüber dem 6.0er zu bieten. Vernünftige C++-Entwicklung ist aber eigentlich erst mit dem 7.1er möglich. Bessere, pingeligere Warnings, recht hohe Standard-Konformität und weniger ICEs zeichnen des aus. Leider ist die IDE immernoch recht Buggy, aber am Compiler kann man wenig aussetzen. Zumal auch der GCC nicht alles findet das man warnen sollte. Wenn man kann und eh portabel codet bietet es sich an den Code immer auf mehreren Compilern zu übersetzen.

Und das der Optimizer nicht dabei ist weil er nix gebracht hätte ist natürlich Polemik. Einfach mal die das 2003er Toolkit gratis und legal von http://msdn.microsoft.com/visualc/vctoolkit2003/ saugen, den Compiler optimierend gegen den unoptimierten Code der Standard-Version antreten lassen und über den Gewinn freuen. Natürlich ist der _immer_ abhängig vom Problem, aber der reisst teilweise schon ganz schön was weg, bei meiner Bytecode-VM zum Beispiel Faktor 4-5 gegenüber unoptimiertem Code.

Okay, wenn man sich Assembler-Code ansieht, findet man schon noch Verbesserungspotential, aber das war auch beim vielgepriesenen guten alten Watcom so (auch wenn der heute gerne glorifiziert wird). Der war zwar für die Zeit schon nicht schlecht, aber sein Code taugt heute auch nix mehr, weil er nix von aktuellen Pipelines und anderen Dingen weiss, davon das er _weit_ weg vom Standard ist mal abgesehen. Selbst für den Intel-Compiler gilt das, der natürlich durchaus noch schnelleren Code erzeugt (die haben sich auch reichlich Fachleute besorgt), leider aber nicht billig ist.

Wer jetzt meint meine VM-Ergebnisse seien ein Sonderfall, dem sei gesagt die vermeintlichen Faktor 5-10 in Assembler eben auch, eine normale komplexe Anwendung schreibt man a) nicht mehr oft in Assembler und b) würde sie eben nicht durchweg Faktor 5-10 schneller sein können. Wenn es denn wirklich mal brennt, kann man gerne das eine oder andere Fragment in Assember machen, aber nur nach Profiling, nicht nach Raten, das klappt nur selten gut.

Die Stellen für die sich Assembler wirklich rentiert sind selten geworden, und die Applikationen die solche Stellen enthalten auch. Spiele sind ein Sektor, manche "Extremaufgaben" (Emulatoren oder ähnliches) sicher auch.

Power Off

Hutzli_ schrieb:

Einfach mal die das 2003er Toolkit gratis und legal von http://msdn.microsoft.com/visualc/vctoolkit2003/ saugen, den Compiler optimierend gegen den unoptimierten Code der Standard-Version antreten lassen und über den Gewinn freuen. Natürlich ist der _immer_ abhängig vom Problem, aber der reisst teilweise schon ganz schön was weg, bei meiner Bytecode-VM zum Beispiel Faktor 4-5 gegenüber unoptimiertem Code.

Danke, werd ich mir mal anschauen!!

Auch, inwieweit Code der Template-Klassen vernünftig reduziert wird.

Oder ob MMX und SSE benutzt werden, wenn's möglich ist. Allein die Register könnte man benutzen, um Stackzugriffe zu sparen.

nman

Power Off schrieb:

Da haste voll recht, die hätten mittlerweile schon längst wenigstens eine ncurses-Version oder eine GUI Version machen können. Aber das kommt ja vielleicht irgendwann noch.

Die Menüsteuerung vom GDB find ich auch zum kotzen.

Es gibt doch nicht nur CLIs zur GDB, KDevelop und Co. haben eigene GDB-Frontends integriert.

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#