Ist C++ durch C11 und C14 wieder populärer geworden?

hustbaer

Einfach funktionieren?

Ne, ehrlich, ist irgendwie ne komische Frage wenn ich schon schreibe dass mir der Vergleich fehlt. (Womit ich sagen wollen: ich kann nicht beurteilen ob er besser ist als andere Debugger, ich kann nur sagen dass er von meinem Standpunkt aus betrachtet einfach sehr gut ist.)

Woher soll ich dann wissen welche der vielen praktischen Funktionen bei anderen Debuggern nicht vorhanden bzw. schlechter gelöst sind?

Was kann der denn so besonders gut?

er ist sehr schnell - beim gdb habe ich immer Verzögerungen an allen Ecken und Enden (bis ein Breakpoint greift usw.)

ich hoffe aber trotzdem auf die lldb-Entwicklung und den positiven Einfluss eines weiteren Debuggers auf dem Spielfeld der Größe erlangen kann

Mechanics

Ich habe jetzt auch nicht wirklich einen Vergleich. Ich habe früher etwas mit gdb und verschiedenen Frontends gearbeitet und fand die überhaupt nicht gut. Und ich habe sehr oft gelesen, dass VS den besten Debugger hätte. Allerdings kann ic jetzt auch nicht sagen, wie fundiert diese Aussagen sind.
Der VS Debugger ist an sich tatsächlich einfach "sehr gut". Er ist schnell, komfortabel, mächtig. Ich kann problemlos mehrere Threads und Prozesse gleichzeitig debuggen, auch remote auf anderen Computern (und muss nicht mal die IP eingeben, der Remote Debugger wird über Broadcasts gefunden). Man kann die Darstellung von Objekten konfigurieren (mit natvis sogar viel bequemer als früher), man kann eigene Visualizer programmieren, man kann Werte live ändern, man kann über die COM Schnittstelle in den Debug Prozess eingreifen, man kann Breakpoints auf API Funktonen setzen, Conditions usw... Und das ist alles schnell und funktioniert einfach.
Dagegen ist der Qt Creator auch nur ein Frontend für den gdb bzw. cdb. Ich kann mir jetzt einfach nicht vorstellen, dass er tatsächlich qualitativ mithalten kann, und ich habe auch nie etwas dergleichen gelesen oder gehört.

Schrauber

Nein, solche Funktionen habe ich beim Qt-Creator noch nicht entdeckt. Da scheint VS doch weit die Nase vorn zu haben.

Ich bezweifle aber stark, dass ich solche Funktionalitäten bei meinen kleinen Einmannprojekten brauchen werde. Viel wichtiger ist mir, dass es egal ist, ob ich nun unter Linux, Windows oder OSX arbeite. Ich habe mir zwei VM mit Linux und OSX angelegt und dort auch Qt installiert und kann sofort dort neu Kompilieren und es läuft. Das hat mich schon beeindruckt.

Wäre wirklich mal schön wenn jemand sich mit dem Qt-Creator und Visual Studio richtig gut auskennen würde. Der kann dann besser vergleichen.

Finnegan

Mechanics schrieb:

Man kann die Darstellung von Objekten konfigurieren (mit natvis sogar viel bequemer als früher), man kann eigene Visualizer programmieren, man kann Werte live ändern...

Im Vergleich zu diversen IDE-Frontends für den GDB fällt mir beim VS Debugger
auch immer wieder auf wie angenehm übersichtlich die Objekte dargestellt werden.
Bei einer std::map habe ich dort z.b. die Element-Paare direkt als erstes sauber in
einer Liste und kann mir bei Bedarf im "Raw View" die darunter liegende Datenstruktur
genauer ansehen. Möglich, dass ich sie falsch benutzt habe, aber bei anderen Debuggern
muss ich mich da meistens durch die interne Datenstruktur der Implementierung hangeln,
um an die Werte zu kommen.

Auch noch positiv: Sind Debug-Informationen und der irgendwoher separat heruntergeladene
Quellcode vorhanden, ist es sehr unproblematisch sich mal eben schnell mit dem Debugger in
ein laufendes Programm einzuhängen und dieses direkt im Quellcode zu debuggen, ohne dass
man dafür ein vollständiges und kompilierbares Projekt benötigt.
Das hatte ich letztens mal mit einem heruntergelanden Programm, bei dem ich nur mal eben
wissen wollte, wie ich einen Bug umschiffen kann, ohne diesen beheben zu müssen,
geschweige denn erstmal das Programm mit all seinen Abhängigkeiten zum kompilieren zu bringen.

Wahrscheinlich geht das alles auch mit alternativen IDEs und Compilern, aber erfahrungsgemäss ist das
dort wesentlich pfriemleliger zu konfigurieren, bis es alles mal läuft. Mit VS bin ich meistens deutlich produktiver.

Finnegan

Artchi

Ich kann den VC++-Debugger nur mit dem der Java-Debugger vergleichen. Und da ist der teilweise sogar fast besser!

Z.B. das Enum-Werte auch ihre Bezeichner darstellen.

Oder das ich schon seit VC++6.0 (1998?) Edit & Continue benutzen kann (also im laufenden Programm Code ändern und die Stelle neu ausführen, während das Programm seinen Zustand behält), hatte mich damals umgehauen. Und als die Java-Kollegen (als ich von C++ zu Java gewechselt bin) mit stolz von ihrem Edit & Continue in der Java IDE erzählten, habe ich nur müde gelächelt.

Und der Debugger hat sich mächtig weiter entwickelt.

Gregor

Nutzt Ihr Debugger eigentlich viel? Ich mache das naemlich nicht. Irgendwie treffe ich nur ganz selten auf Fehler, bei denen ich mir denke, dass ich die am Besten mit einem Debugger angehen kann.

Tyrdal

Ja, der ist extrem wichtig. Hier gibts ne riesige alte Codebasis und fast keine Doku. Da hilft der Debugger schon rauszufinden was jetzt eigentlich so abgeht.

TyRoXx

Gregor schrieb:

Nutzt Ihr Debugger eigentlich viel? Ich mache das naemlich nicht. Irgendwie treffe ich nur ganz selten auf Fehler, bei denen ich mir denke, dass ich die am Besten mit einem Debugger angehen kann.

Ich lasse Tests immer im Debugger laufen, weil ich bei einem Absturz oder einem Deadlock sofort weiß, wo es passiert.

Ab und zu ist es nützlich einen Breakpoint für das Auftreten einer Exception zu setzen. Das bringt natürlich nur etwas, wenn man Exceptions nur für Ausnahmen verwendet.

Manchmal deckt sich das erwartete Verhalten einer Funktion nicht mit dem beobachteten Ergebnis. Da hilft ein Debugger schon immens beim Verstehen.

volkard

Gregor schrieb:

Nutzt Ihr Debugger eigentlich viel?

Hab langsam verlernt, wie man den benutzt.

Gregor

TyRoXx schrieb:

Ich lasse Tests immer im Debugger laufen, weil ich bei einem Absturz oder einem Deadlock sofort weiß, wo es passiert.

Dafuer braucht man ja erstmal keinen Debugger, sondern nur Debug Informationen. In Fortran kompiliere ich Code zum Testen zum Beispiel mit

ifort -warn nousage -traceback -ftrapuv -CB -O0 -g -check uninit -check pointers

Das ist super. Ich kriege damit bei jeder Kleinigkeit einen Fehler mit sehr genauer Angabe, wo der auftritt.

Finnegan

Gregor schrieb:

Dafuer braucht man ja erstmal keinen Debugger, sondern nur Debug Informationen. In Fortran kompiliere ich Code zum Testen zum Beispiel mit
ifort -warn nousage -traceback -ftrapuv -CB -O0 -g -check uninit -check pointers
Das ist super. Ich kriege damit bei jeder Kleinigkeit einen Fehler mit sehr genauer Angabe, wo der auftritt.

Das fällt war streng genommen unter "keinen Debugger benutzen", als verwöhnter IDE-User drücke ich da aber lieber zum starten einfach "die andere" Taste und starte das Programm im Debugger um an diese Informationen zu kommen.
Zumal ich dann auch noch gleich den Quellcode-Kontext sehe in dem der Fehler aufgetreten ist und mir ansehen kann was denn grad im Speicher so los ist.

Finnegan

Mechanics

Gregor schrieb:

Nutzt Ihr Debugger eigentlich viel?

Ja, sehr viel. Wir haben sehr viel sehr "komplexen" Code. Komplex nicht im Sinne von hochkomplexe mathematische Algorithmen (haben wir auch, aber nicht meine Baustelle), sondern komplex im Sinne von verteilt über zig Komponenten und Prozesse und sehr viel Code von 100 Leuten über Jahrzehnte hinweg geschrieben und keiner kennt sich komplett aus usw...

Gregor

Mechanics schrieb:

Gregor schrieb:

Nutzt Ihr Debugger eigentlich viel?

Ja, sehr viel. Wir haben sehr viel sehr "komplexen" Code. Komplex nicht im Sinne von hochkomplexe mathematische Algorithmen (haben wir auch, aber nicht meine Baustelle), sondern komplex im Sinne von verteilt über zig Komponenten und Prozesse und sehr viel Code von 100 Leuten über Jahrzehnte hinweg geschrieben und keiner kennt sich komplett aus usw...

Mein Eindruck ist eigentlich, dass Debugger bei zunehmender Komplexitaet des Codes immer weniger bringen. Komplexitaet heisst fuer mich in diesem Fall, dass ein lokales Verstaendnis einer Codestelle nicht ausreicht, um den Code debuggen zu koennen. Debugger sind aber gerade darauf ausgelegt, lokal eingreifen zu koennen und sich den lokalen Zustand des Programms an einer Stelle anzugucken.

Shade Of Mine

Gregor schrieb:

Mechanics schrieb:

Gregor schrieb:

Nutzt Ihr Debugger eigentlich viel?

Ja, sehr viel. Wir haben sehr viel sehr "komplexen" Code. Komplex nicht im Sinne von hochkomplexe mathematische Algorithmen (haben wir auch, aber nicht meine Baustelle), sondern komplex im Sinne von verteilt über zig Komponenten und Prozesse und sehr viel Code von 100 Leuten über Jahrzehnte hinweg geschrieben und keiner kennt sich komplett aus usw...

Mein Eindruck ist eigentlich, dass Debugger bei zunehmender Komplexitaet des Codes immer weniger bringen. Komplexitaet heisst fuer mich in diesem Fall, dass ein lokales Verstaendnis einer Codestelle nicht ausreicht, um den Code debuggen zu koennen. Debugger sind aber gerade darauf ausgelegt, lokal eingreifen zu koennen und sich den lokalen Zustand des Programms an einer Stelle anzugucken.

Ich sehe das genau umgekehrt: Debugger sind dann genial wenn es nicht um eine limitierte Codestelle geht sondern um komplexe Abhängigkeiten zu anderen Codestellen. Denn lokal limitierte Fehler sind relativ simpel auch ohne Debugger zu finden. Gerade aber wenn die Abhängigkeiten zu anderen Codestellen komplex werden, dann sind Debugger enorm hilfreich.

Schrauber

Wenn man viel OOP macht, ist es dann überhaupt noch gut möglich den eigentlichen Signalfluß zu überblicken? Ich stelle mir das gruselig vor, erst recht wenn das Code von einem Fremden ist.

Shade Of Mine

Schrauber schrieb:

Wenn man viel OOP macht, ist es dann überhaupt noch gut möglich den eigentlichen Signalfluß zu überblicken? Ich stelle mir das gruselig vor, erst recht wenn das Code von einem Fremden ist.

Was hat das mit OOP zu tun?

Mein Vater druckt sich für seine 100-200 Zeilen langen Funktionen gerne Struktogramme aus. Sowas macht natürlich keinen Sinn, aber deswegen ist es noch lange nicht gruselig.

Schrauber

Na, ich stelle mir das ziemlich wüst vor, wenn an einem Prozess ziemliche viele Klassen beteiligt sind. Da durchzusteigen, besonders wenn man es nicht selbst geschrieben hat, ist bestimmt schwer.

Techel

Dafür gibt es die beiliegenden Dokumentation.

C++ geht das doch ganz gut, den Flow nachzuvollziehen.

Entwickelt mal eine schöne Spring-Applikation in Java (mit JPA und allem drum und dran) und sagt, dass ihr das könnt.