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

Winn

Jester schrieb:

Dann verstehe ich nicht, warum Du krampfhaft nach Aussagen über hohe Entwicklungszeiten suchst.

Weil ich es gerne wasserdicht hätte... was ich nur während dieser Diskussion erkenne, ist, daß dahinter eine Schwachstelle vermutet wird und ohne das ich so etwas beabsichtige ich mir damit mein Boot selbst schiffsuntüchtig schieße... also werde ich es wohl sein lassen

Jester schrieb:

Deine Geldgeber haben den Zeitplan doch sicher mit Dir zusammen durchgesehen?

Nein, daß ist nicht passiert - der Plan wurde ohne mich abgesprochen und mir bei Beginn als Arbeitsplan vorgelegt.

hustbaer

@Winn:

Ich wollte oder möchte deren Vertrauen durch eine Veröffentlichung zu diesem Thema stützen...

Du willst dich (und deine Arbeit, wozu die Wahl von C++ als Werkzeug gehört) also gut verkaufen. Gut verkaufen tut man IMHO sich auf jeden Fall nicht damit indem man ungefragt eine "Entschuldigung" für etwas bringt was vielleicht garnicht in Frage gestellt würde.

Genausowenig würde ich es als "sich gut verkaufen" bezeichnen wenn man erstmal nen Haufen Nachteile von C++ aufzählt um damit quasi zu begründen warum man solange gebraucht hat -- dann wäre sofort die Frage da "warum hat der Dolm dann überhaupt C++ verwendet". Auch wenn du die Frage dann beantworten kannst, besser sie kommt garnicht erst auf.

Wenn du also gute Gründe hast warum C++ deiner Meinung nach das richtige Werkzeug ist, dann verkaufe diese Gründe -- aber nicht so dass es nach einer Rechtfertigung klingt. Oder du gehst von selbst garnicht darauf ein, und wartest ob du gefragt wirst. Für den Fall dass das passiert kannst du ja was vorbereiten.

Genauso die Fortschritte die du erzielt hast. Du sagst du liegst in der Zeit - was willst du also noch mehr? Programmier-Projekte sind so wie Hausbauen - jeder sagt er braucht 2 Monate für irgendwas, und in wirklichkeit werden es dann 3 oder 4. Wenn du in 2 Jahren die Arbeit gemacht hast für die 2 Jahre veranschlagt waren kannst du IMHO darauf schon stolz sein. Wenn deine Geldgeber Erfahrung in dem Bereich (Software Projekte) haben sollten sie das selbst wissen, und nicht auf die Idee kommen zu fragen warum du nicht mehr geschafft hast als die Milestones die ausgemacht waren.

Nur meine 2 Cent...

Gregor

Winn schrieb:

ten schrieb:

guckst du: http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpprt_computer2000.pdf
unter 'work time and productivity'

Weltklasse ! Ich hatte gehofft, daß es irgendwo ein Paper dazu gibt.... Besten Dank !

Ich würde das Paper da nicht überbewerten. Alleine dadurch, dass es aus dem Jahr 2000 ist, sind die darin getroffenen Aussagen heute praktisch nicht mehr zutreffend. C# tritt in dem Paper zum Beispiel noch gar nicht auf, bei Java wurde Version 1.2 verwendet, wo jetzt Java 6 aktuell ist. Da hat sich einiges getan, was Bibliotheken, Werkzeuge usw. betrifft. Und wie hier ja schon gesagt wurde, haben die Werkzeuge und Bibliotheken einen enormen Einfluss auf die Produktivität. Ich habe zudem den Eindruck, dass sich zwischen dem Jahr 2000 und jetzt einiges an der Art und Weise geändert hat, wie man C++ programmiert. Auch das wird einen enormen Einfluss haben.

Abgesehen davon ist so ein Paper sehr speziell. Die Aussagekraft geht nicht weit über das dort geschriebene Programm hinaus. Wenn ein etwas anderes Programm gewählt worden wäre, hätte vielleicht bei irgendeiner Sprache eine besonders gute Bibliothek das Ergebnis völlig verändert. Ich würde es eigentlich sogar als unseriös bezeichnen, soetwas als "wissenschaftliches" Paper zu veröffentlichen. Die einzig wirklich interessante Information, die IMHO darin enthalten ist, betrifft die Unterschiede zwischen Programmierern. Dort wird gesagt, dass die viel größer sind als die Unterschiede zwischen den Programmiersprachen.

tfa

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.

tfa

ten

tfa schrieb:

Hat man in C++ auch ausführliche Stacktraces?

hat man, kommt auf den debugger an.
man kann den quelltext durchsteppen, sich variablen ansehen, ändern usw...

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?