Zeitbedarf für Projekte je nach gewählter Programmiersprache gesucht...

hustbaer

tfa schrieb:

Artchi schrieb:

Wenn ich Fehler mache, hilft mir Java nicht viel weiter, als wenn ich Fehler in C++ mache.

Echt nicht? Hat man in C++ auch ausführliche Stacktraces?
(...)

Kommt auf die Plattform drauf an, und ob man irgendwelche speziellen Libs verwendet die das u.U. können.
Normalerweise hat man aber bei einem Release Build, also z.B. wenn der Fehler beim Kunden passiert, mit C++ weniger als mit Java.

Artchi

tfa schrieb:

Artchi schrieb:

Wenn ich Fehler mache, hilft mir Java nicht viel weiter, als wenn ich Fehler in C++ mache.

Echt nicht? Hat man in C++ auch ausführliche Stacktraces?
Hab lange nix mehr in C gemacht und kann mich nur noch ein
mehr oder weniger riesige Coredumps erinnern.

Also man kann wie in Java debuggen, auch zur Laufzeit Code ändern und dann wird der geänderte Code zur Laufzeit übernommen (gibt Ausnahmesituatonen, wo es nicht geht, ist aber in Java auch so). Stacktraces gibts natürlich auch, kann auch Variablen zur Laufzeit ändern usw. Aber das konnte man auch schon damals mit VC++6. Es gibt auch einen Debugger unter Linux, mit dem du sogar rückwärts debuggen kannst: http://www.undo-software.com/

C++ und die Tools entwickeln sich (man soll es nicht glauben) auch weiter.

Redet ihr jetzt vom Callstack im Debugger oder gibt es wirklich die möglichkeit in C++ den stacktrace zu loggen, wenn eine Exception aufgetreten ist? Hängt an der Exception der Stacktrace dran, damit ich mir ausgeben kann, woher sie kommt? In Java kann ich oft schon sagen, was der Fehler war ohne den Debugger erst starten zu müssen.
Wenn es hier ne Möglichkeit gibt, würde mich das interessieren wie.

try {
   //Funktionen
} catch (...) {
   //In welcher funktion war der Fehler an welcher stelle?
}

Artchi

Achso, neee, ich bin vom Debugger ausgegangen. Also Callstack. Aber etwas ähnliches wie einen Stacktrace kann man auch in C++ einbauen. Zumindest das man sich die Zeilennummer und Datei ausgibt:

std::string s("Fehler in ");
s += __FILE__ ;  // Predefined Standard-Makro
s += " und Zeile ";
s += __LINE__ ; // Predefined Standard-Makro

throw std::runtime_error(s);

Vorzugsweise sollte man sich das natürlich etwas komfortabler machen. Aber so hat man zumindest im Release in der Log-Datei einen Hinweise auf die Stelle im Code. Am besten man benutzt auch noch eine Logging-Library, dann kann man auch mehr sehen, wo und was passiert ist. Mit plain-C++ ohne nichts wirds schwierig. Aber es hindert einen keiner daran solche Möglichkeiten zu nutzen.

tfa

sag genau schrieb:

Redet ihr jetzt vom Callstack im Debugger oder gibt es wirklich die möglichkeit in C++ den stacktrace zu loggen, wenn eine Exception aufgetreten ist? Hängt an der Exception der Stacktrace dran, damit ich mir ausgeben kann, woher sie kommt? In Java kann ich oft schon sagen, was der Fehler war ohne den Debugger erst starten zu müssen.

Genau das meinte ich. Was nützten mir Callstacks im Debugger wenn die Fehler beim Kunden in der Produktivumgebung auftreten? In Java bekomme ich einen ausführlichen Stacktrace mit Klassen- und Methodennamen und den genauen Zeilennummern. Dies zusammen mit Informationen über Laufzeitumgebung, Client-Hardware, Undo-Puffer und den Logdaten der letzten 5 Minuten, einem Screenshot und Kommentar des Anwenders per Mail ans Backoffice gesendet und das Problem ist halb gelöst (naja, häufig jedenfalls).

Von da her würde ich schon sagen, dass Java bei der Fehlersuche und -behebung von Haus aus sehr viel mehr zu bieten hat als C++.

tfa

nep

Naja das ist aber auch ein bisschen Ansichtssache. In einer PRODUKTIVumgebung sollten solche Sachen normalerweise auch gar nicht vorfallen (klar in der Praxis sieht es anders aus). Aber da siehst du ja auch nicht viel mehr als in welcher Methode was für ein Fehler aufgetreten ist. Kann man in C++ durch entsprechendes Logging und prägnanten Fehlermeldungen genauso erreichen. Und dann musst du in beiden Umgebungen in der Methode den Fehler ausmärzen.
Ich würde nicht unbedingt sagen, dass Java da viel mehr zu bieten hat. Würde eher sagen, dass Java die ganze Sache etwas komfortabler macht und nicht so viel Disziplin wie bei C++ verlangt, was aber natürlich auch einiges wert ist.

Natürlich hat Java viel mehr zu bieten, was die Fehlersuche angeht.
Wenn ich sowas wie
NullPointerException
at xyz.do 457
at abc.foo 87
at main 56

Bekomme, dann weiß ich gleich wo der Fehler ist, was aufgerufen wurde usw. Oft reicht es dann schon den Code nochmal genau anzuschauen und man weiß schon was nicht stimmt.

Wenn ich dagegen
Access violation at address 001475FE in module nase
bekomm, dann freu ich mich richtig und hoffen, dass ich an genügen stellen geloggt habe, um den Fehler einigermasen nachfolziehen zu können.
Und das kann auch passieren, wenn das Produkt intern getestet wird.

Artchi

Oh man, gibts hier keinen Smily "mit dem Kopf an die Wand hau"?? Man darf hier wirklich nicht das Wort Java in den Mund nehmen. Ich muß mir das einfach für die Zukunft merken.

Also, das man am Stacktrace in Java sehen kann, an welcher Stelle eine Exception passiert ist, stimmt. Aber, seien wir ehrlich? Was sind denn die häufigsten Exceptions in Java? Ich gehe jetzt mal von meiner pers. Erfahrung aus: ClassCastException, NullPointerException und vielleicht das ne Connection zu einer Datenbank oder Server nicht funktioniert. Hem... überleg. Also erste Exceptiontypen habe ich in C++ praktisch so gut wie nie Templates. NullPointer bin ich in C++ gewöhnt auf Null abzufragen, meistens benutz man in C++ aber keine Pointer. Hebt sich alles irgendwie wieder aus, da wo C++ was fehlt, macht es wieder mit anderen Möglichkeiten wieder wett. Und die Maktos __FILE__ und __LINE__ sind ja auch noch da.

Aber am Ende muß ich nep einfach zustimmen: im produktiven System sollten unkontrollierte Exceptions nicht auftreten. Und das tut es bei meinen Projekten auch sehr selten. (selten! nicht nie!) Deshalb bin ich bei meinen Postings hier auch immer eher vom Debugger ausgegangen. Meistens kann man durch Unittests und QS-Abteilung die meisten Fehler vor dem Produktivgang verhindern.

hustbaer

Neh, also so würde ich das nicht sagen
Ich kenne aus der Praxis schon den Fall (bzw. die Fälle, garnicht wenige), wo jmd. nen Screenshot von einer Access Violation schickt und wir dann Tagelang rätseln und suchen durften wieso das passiert - und oft auch wo. Bzw. wenn man vielleicht sogar weiss in welcher Funktion -- wie sieht der Callstack drunter aus?
Das alles kann beim Fehlersuchen schon ungemein hilfreich sein.

Was Unit Tests, gute QA Abteilung etc. angeht - es arbeitet nunmal nicht jeder in einem Bereich wo man sich Qualität leisten kann. Eine Software die halbwegs funktioniert aber nicht wirklich gut getestet ist zu entwickeln kostet nunmal erheblich weniger als eine wirklich gut getestete bei der kaum noch Fehler auftreten werden.

Auf der einen Seite haben wir Raketensteuerungssysteme, medizinische Geräte etc., auf der anderen eben Shareware Spiele und dergleichen.

Daher kann ich das "egal, weil in der fertigen Software sowieso kaum Fehler drin sein sollten" einfach nicht als allgemeingültige Aussage akzeptieren -- weil es nicht realistisch ist.

Immer wenn java was besser kann, dann sagt ihr nur, "den Fehler mach ich nicht" oder "Und wenn man in C++ das und das verwendet und das noch einbaut, dann ist es fast wie Java". Wieso könnt ihr dann nicht einfach zugeben, das Java da besser ist.

Simon2

Hä ???
Wie kommt denn hier jemand von Winns Frage auf "Java vs C++" ?
Leute, lasst Euch doch nicht von einem Post aufs Glatteis führen.

Wäre so einfach gewesen:

tfa schrieb:

Artchi schrieb:

Wenn ich Fehler mache, hilft mir Java nicht viel weiter, als wenn ich Fehler in C++ mache.

Echt nicht? Hat man in C++ auch ausführliche Stacktraces?...

Antwort: Ist egal ! Hat damit nichts zu tun !

Fertig.

Oder glaubt wirklich jemand, dass Winn in seinen Projektantrag etwas über Stacktraces schreiben will/soll ?

Gruß,

Simon2.

Blue-Tiger

Simon2 schrieb:

Hä ???
Wie kommt denn hier jemand von Winns Frage auf "Java vs C++" ?
Leute, lasst Euch doch nicht von einem Post aufs Glatteis führen.

Wäre so einfach gewesen:

tfa schrieb:

Artchi schrieb:

Wenn ich Fehler mache, hilft mir Java nicht viel weiter, als wenn ich Fehler in C++ mache.

Echt nicht? Hat man in C++ auch ausführliche Stacktraces?...

Antwort: Ist egal ! Hat damit nichts zu tun !

Oder glaubt wirklich jemand, dass Winn in seinen Projektantrag etwas über Stacktraces schreiben will/soll ?

Es ging darum dass C++ oft umstaendlicher als andere Sprachen ist, also ist das Beispiel "andere Sprachen haben bei Exceptions automatisch ausfuehrliche Stacktraces, C++ nicht" sehr wohl Teil der Diskussion

Artchi

@hustbaer! Ja, eine QS-Abteilung gibt es nicht überall, kostet Geld. Ich habe auch nicht immer in Projekten mit QS-Abteilungen gearbeitet. Weißt du was? Um so mehr habe ich mich bemüht Fehler zu vermeiden.
Wenn ihr Exception-Screenshots bekommt, kann man die Fehlersituation (wir fragen die User dann, wann und wie der Fehler auftrat, selbst mit Stacktrace) nicht reproduzieren?

Ja, kann man reproduzieren? Dann braucht man keinen Stacktrace, sondern man kann den Debugger anschmeissen und die Stelle wird gefunden durch Fehlerreproduktion.
Nein? Dann hilft dir in Sprache-X auch kein Stacktrace.

Und? Schön das Sprache-X das eine Feature hat, was C++ nicht hat. Aber man kann auch sehr schön den Spiess umdrehen, und Fragen stellen, wo Sprache-X ein Defizit hat. Z.B. die von mir genannten Templates kann ich schon mal ClassCasts Exceptions verhindern. Interessiert aber die Sprache-X-Fans nicht die Bohne, das Argument. Warum nicht? Weil C++-Features eh schlecht sind, wenn Sprache-X das nicht hat?

Den Java vs. C++ Thread hatten wird doch schon vor 1 - 2 Wochen. Wir brauchen nicht schon wieder einen. Sagen wir einfach C++ hat gewonnen, OK?

Gregor

Artchi schrieb:

Und? Schön das Sprache-X das eine Feature hat, was C++ nicht hat. Aber man kann auch sehr schön den Spiess umdrehen, und Fragen stellen, wo Sprache-X ein Defizit hat. Z.B. die von mir genannten Templates kann ich schon mal ClassCasts Exceptions verhindern. Interessiert aber die Sprache-X-Fans nicht die Bohne, das Argument. Warum nicht? Weil C++-Features eh schlecht sind, wenn Sprache-X das nicht hat?

Musst Du in der Firma eigentlich noch mit Java 1.4 arbeiten?

Ich schon

Gregor

Arbeiter schrieb:

Ich schon

Mag schon sein. Und ich kenne auch jemanden, der in der Firma noch Java 1.3 nutzen muss. Trotzdem sollte man diese Versionen nicht für einen heutigen Vergleich von Programmiersprachen heranziehen, denn solche Vergleiche sind nur dann von Interesse, wenn man überhaupt die Wahl hat. Und da wäre die Java-Option eben Java 6. Das bietet längst Möglichkeiten, um unsichere Downcasts im Quellcode zu vermeiden. Die Generics in Java bieten auch die Möglichkeit, die geforderte Schnittstelle formal anzugeben, was entsprechende produktivitätssteigernde Funktionen der IDEs nach sich zieht.

nep

Ich finde das ganze sowieso etwas sinnlos. Ich habe z.B. nie bestritten, dass Java nicht z.B. komfortabler bei gewissen Dingen der Fehlerbehandlung ist. Ist es ja auch. Nur finde ich, dass es einfach nicht stimmt, dass Java da jetzt großartige revolutionäre Neuheiten hat, womit die Fehlersuche viel schneller klappt als mit C++. Und da finde ich eben das Beispiel das da angeführt wurde, dass man in einer angeblichen Produktivumgebung ja sofort den Fehler anhand des Stacktraces ausbügeln kann, etwas aus der Welt gegriffen. Mag ja sein, dass das mal vorkommt, aber normalerweise sollten, wie Artchi schon meinte, nicht irgendwelche Exceptions wild in der Gegend rumfliegen. Zumindest nicht in Produktivumgebungen.

Ausserdem ist es mir neu, dass man bei großen Software-Produkten einfach mal nen Fehler mittels Screenshot von nem Stacktrace beheben kann. Also da wo ich mal gearbeitet habe, da wurde nicht nur einfach mal der Stacktrace an den Support geschickt und dann wurde der Fehler behoben...so einfach geht das doch nicht. Ich weiß echt nicht was manche Leute da für eine Vorstellung haben...

hustbaer

Artchi schrieb:

@hustbaer! Ja, eine QS-Abteilung gibt es nicht überall, kostet Geld. Ich habe auch nicht immer in Projekten mit QS-Abteilungen gearbeitet. Weißt du was? Um so mehr habe ich mich bemüht Fehler zu vermeiden.

Entweder hast du noch nicht mitbekommen wie es in manchen Firmen läuft, oder du misverstehst mich absichtlich.
Wenn es heisst "wir brauchen das Release in N Tagen" dann kannst du dich noch so bemühen -- wenn das was noch fehlt normalerweise 2*N Tage dauern wird, dann wird auch mit deinem "um so mehr bemühen" in der Zeit die "das Management" einem zugesteht nix ordentliches draus werden.
Und was machst du mit fürchterlichem legacy Code, den du übernommen hast? Ganz doll nicht daran denken, und gucken dass jmd. anderer den Fehler sucht wenn einer auftritt? Pf.

Wenn ihr Exception-Screenshots bekommt, kann man die Fehlersituation (wir fragen die User dann, wann und wie der Fehler auftrat, selbst mit Stacktrace) nicht reproduzieren?

Nein. Oft nicht. Oft bekommen wir als Info nichtmal welche Version der Software da überhaupt läuft. Geschweige denn einen Stacktrace. Oder es ist aus anderen Gründen (auf die ich jetzt nicht näher eingehen will -- die ich aber im Moment auch nicht ändern kann) nicht möglich passende PDB Files zu dem zu bekommen was irgendwann mal als Release rausgegangen ist. Und ohne PDB Files...

Ja, kann man reproduzieren? Dann braucht man keinen Stacktrace, sondern man kann den Debugger anschmeissen und die Stelle wird gefunden durch Fehlerreproduktion.

Ja, kann blablubb. Ich kann auch zu Fuss 100km gehen. Ich fahre trotzdem lieber, geht einfach schneller.

Nein? Dann hilft dir in Sprache-X auch kein Stacktrace.

Gerade bei einem Fehler den ich (ohne Stacktrace) nicht reproduzieren kann weil ich nichtmal genau weiss wo er auftritt hilft mir ein Stacktrace. *verwirr* ?!?

Und? Schön das Sprache-X das eine Feature hat, was C++ nicht hat. Aber man kann auch sehr schön den Spiess umdrehen, und Fragen stellen, wo Sprache-X ein Defizit hat. Z.B. die von mir genannten Templates kann ich schon mal ClassCasts Exceptions verhindern. Interessiert aber die Sprache-X-Fans nicht die Bohne, das Argument. Warum nicht? Weil C++-Features eh schlecht sind, wenn Sprache-X das nicht hat?

Was is jetzt schonwieder kaputt? Darum gehts mir doch garnicht. Ich schreibe ganz gerne in C++, ich mag meine Templates, ich mag mein const, ich mag auch ganz gerne meine unsigned integers etc. -- das änder aber nix daran dass gewisse Dinge in C++ viel umständlicher sind als sie es sein müssten. Und umständlicher sind als in anderen Sprachen.

Du regst dich darüber auf dass die "X-Anhänger" alles für doof erklären was C++ mehr kann, tust selber aber nicht gerade etwas grundlegend anderes -- indem du eben ein "Feature" von Java kleinredest welches eben nicht so klein ist.
Stacktraces sind eine tolle Sache, und ich würde mich freuen wenn ich das in C++ auch hätte. Punkt.

Simon2

Blue-Tiger schrieb:

....
Es ging darum dass C++ oft umstaendlicher als andere Sprachen ist, also ist das Beispiel "andere Sprachen haben bei Exceptions automatisch ausfuehrliche Stacktraces, C++ nicht" sehr wohl Teil der Diskussion

Nö.

Die Frage war, ob es wissenschaftliche Untersuchungen dazu gäbe, dass Entwicklungsprojekte unter C++ deutlich langsamer wären als an (allen ?) anderen Sprachen.

Eigentlich hat sich längst herausgestellt, dass bereits die Frage wenig sinnvoll ist ... und es wurde definitiv nicht danach gefragt, wo irgendjemand persönlich sich vorstellen könnte, dass Java "besser" sein könnte. Das hilft dem OP nämlich gar nicht und wenn jetzt jeder dieses oder jenes einzelne Feature anführt und durchdiskutiert: Für eine Begründung könnte er sowieso nicht schreiben "Habe die im C++-Forum auch gemeint" (selbst wenn wir hier eine einheitliche Meinung hätten).
... und wenn er schon nicht schreiben kann, was er selbst als Schwierigkeit konkret erlebt (oder noch vor sich) hat, wird ganz bestimmt "Hörensagen" da nicht weiterhelfen.

Gruß,

Simon2.