C++ schneller als andere Sprachen?
-
BarnieGeroellheimer schrieb:
Weißt du was die erste Reaktion war als ich vor etwa einem halben Jahr meinen Chef gesagt habe das es eine Sprache+UI gibt, die seine UI-Anforderungen und die der Kunden weitgehend zufriedenstellen könnte, als ich den Nachteil (Lauffähig erst ab XP Servicepack 2) genennt hatte.
Dann muß das der Kunde bezahlen, wenn er spezielle Anforderungen hat. Die meisten Chefs haben aber leider keinen ***** in der Hose.
Der Chef ist mehr das Problem als die Kunden. Die wären schon zufrieden wenn man 25% aller Fehler beseitigen würde.
cu André
-
Was ich nicht kapiere: Einerseits sollen die Daten im Editor editierbar sein. Andererseits soll per Checksumme verhindert werden, dass der Kunde die Daten editiert. Wie nun?
Edit: Ups, sorry, falscher Thread. Sollte nach nebenan in den Datenformat-Thread...
-
muemmel schrieb:
Hi,
was ich immer noch nicht so ganz verstehen kann, ist das herumreiten aurf Portabilität. Sicher, für manchen ist es wichtig, aber ich behaupte mal, daß 95% aller Programmierer nur für eine Umgebung coden. Wer macht denn wirklich regelmäßig Programme, die sowohl unter Win als auch unter Linux, Unix und Mac laufen müssen.
Mir ist Portabilitaet sehr wichtig, da mein Kundenkreis eher begrenzt ist und ich somit niemanden ausschliessen kann/will.
Aber was ist bitte der "kleinste gemeinsame Nenner"? Opera sieht doch nicht schlecht aus oder? Ist in GTK+ geschrieben. Oder QT: Skype, Adobe Photoshop Album, KDE, uvm.
http://trolltech.com/company/customers/coolappsOder Java: http://java.dzone.com/tips/ten-amazing-java-applications
Wenn man das richtige Framework hat ist Plattformunabhaenigkeit geschenkt.
-
Hi,
na gut, da hat sich doch in letzter Zeit einiges getan. Erinnere mich noch an einen Versuch mit WordPerfect unter Linux, sah einfach nur gruselig aus und war für mich recht abschreckend.
Wenn man tiefer aufbohren will, speziell die neuen Möglichkeiten und Spielereien von Vista, dann ist Portabilität aber schnell an ihre Grenze gekommen.Gruß Mümmel
-
muemmel schrieb:
Wenn man tiefer aufbohren will, speziell die neuen Möglichkeiten und Spielereien von Vista, dann ist Portabilität aber schnell an ihre Grenze gekommen.
Gruß Mümmel
Welche gibts den da?
-
Hi,
zum Beispiel in der VCL die VISTA-Dialogfelder.
Auch bin ich mir nnicht so ganz im klaren, ob mal kurz zu Hilfe genommene OCX/VCX-Tools woanders auch zur Verfügung stehen. Sicher, irgendwie geht immer alles, aber oft heißt das eben auch mehr bezahlen.Gruß Mümmel
-
direkt gegen die windows API zu entwickeln ist ja sowieso gruselig. wer macht das schon freiwillig?
-
ICH!
-
Erhard Henkes schrieb:
Von schnell zu langsam: ASM > C ~ C++ > Java (grobe Abstufung)
Hier kannst Du dir einige Benchmarks anschauen:
http://shootout.alioth.debian.org/Unreflektieres Geschwätz. Ohne Beschreibung der Umgebung
(Server vs. Client, langlaufender Prozess vs. one-time-run)
usw. ist keine Aussage möglich. Gerade im ersten Fall
ist Java oft um Größenordnungen schneller.Bei Clients, im speziellen GUIs stimmt deine Aussage, mir
geht nur das permanente, planlose "Java-ist-langsam" Gelalle
auf den Sack. Langsam ist AWT/Swing, daher auch der schlechte
Ruf. z.B. auf dem Server schauts eben anders aus.btw:
Von der Zeit zur Fehlersuche (uihhhh, delete vergessen) und
zur Wartung der Programme reden wir hier ja nicht, da wären
es nochmal 10er Potenzen mehr, die Java schneller ist.
-
Serverentwickler schrieb:
Erhard Henkes schrieb:
Von schnell zu langsam: ASM > C ~ C++ > Java (grobe Abstufung)
Hier kannst Du dir einige Benchmarks anschauen:
http://shootout.alioth.debian.org/Unreflektieres Geschwätz. Ohne Beschreibung der Umgebung
(Server vs. Client, langlaufender Prozess vs. one-time-run)
usw. ist keine Aussage möglich. Gerade im ersten Fall
ist Java oft um Größenordnungen schneller.um groessenordnungen? so ein bloedsinn. dann waere c++ weit von dem entfernt was hardware leisten kann, tztz. redest hier von geschwaetz aber kommst mit so nem blablub.
Von der Zeit zur Fehlersuche (uihhhh, delete vergessen) und
zur Wartung der Programme reden wir hier ja nicht, da wären
es nochmal 10er Potenzen mehr, die Java schneller ist.so ein dummfug geht mir wiederrum auf den sack, als ob man irgend nem marketing geschwaetz glauben sollte als rational denkender entwickler. oder um es auf deine stumpfe art zu sagen: uihhhh, referenz vergessen.
-
rapso schrieb:
Serverentwickler schrieb:
Erhard Henkes schrieb:
Von schnell zu langsam: ASM > C ~ C++ > Java (grobe Abstufung)
Hier kannst Du dir einige Benchmarks anschauen:
http://shootout.alioth.debian.org/Unreflektieres Geschwätz. Ohne Beschreibung der Umgebung
(Server vs. Client, langlaufender Prozess vs. one-time-run)
usw. ist keine Aussage möglich. Gerade im ersten Fall
ist Java oft um Größenordnungen schneller.um groessenordnungen? so ein bloedsinn. dann waere c++ weit von dem entfernt was hardware leisten kann, tztz. redest hier von geschwaetz aber kommst mit so nem blablub.
Optimierungen zur Laufzeit können durchaus Größenordnungen schneller machen
also solche zur Entwicklungszeit. Zudem kann dann auch adaptiv optimiert
werden. Diesen Vorteil kann C++ nicht aufholen (bei langlaufenden Anwendungen).rapso schrieb:
Von der Zeit zur Fehlersuche (uihhhh, delete vergessen) und
zur Wartung der Programme reden wir hier ja nicht, da wären
es nochmal 10er Potenzen mehr, die Java schneller ist.so ein dummfug geht mir wiederrum auf den sack, als ob man irgend nem marketing geschwaetz glauben sollte als rational denkender entwickler. oder um es auf deine stumpfe art zu sagen: uihhhh, referenz vergessen.
Das sagt nicht das Marketing, sondern die Erfahrung.
-
Serverentwickler schrieb:
mirgeht nur das permanente, planlose "Java-ist-langsam" Gelalle
auf den Sack.es ist nun mal das einzige argument, dass C++ fanboys gegen Java anführen können.
aber das schlimme ist, manchmal stimmt es sogar.
-
Ja, manchmal stimmt es wirklich. Bei GUIs z.B. oder bei sehr
rechenlastigen Anwendungen, allerdings sind die besten libs da immer
noch in Fortran geschrieben. Auch für Hardwarenahe Entwicklung is
C++ besser, allerdings sehe ich C als noch besser geeignet an.
-
Penschmark schrieb:
Optimierungen zur Laufzeit können durchaus Größenordnungen schneller machen
In welchem Zahlensystem?
-
Penschmark schrieb:
rapso schrieb:
Serverentwickler schrieb:
Erhard Henkes schrieb:
Von schnell zu langsam: ASM > C ~ C++ > Java (grobe Abstufung)
Hier kannst Du dir einige Benchmarks anschauen:
http://shootout.alioth.debian.org/Unreflektieres Geschwätz. Ohne Beschreibung der Umgebung
(Server vs. Client, langlaufender Prozess vs. one-time-run)
usw. ist keine Aussage möglich. Gerade im ersten Fall
ist Java oft um Größenordnungen schneller.um groessenordnungen? so ein bloedsinn. dann waere c++ weit von dem entfernt was hardware leisten kann, tztz. redest hier von geschwaetz aber kommst mit so nem blablub.
Optimierungen zur Laufzeit können durchaus Größenordnungen schneller machen
also solche zur Entwicklungszeit. Zudem kann dann auch adaptiv optimiert
werden. Diesen Vorteil kann C++ nicht aufholen (bei langlaufenden Anwendungen).natuerlich kannst du ein profiling durchlauf machen und danach nochmals compilieren mit diesen daten. da das ganze gezielt passiert und nicht sporadisch, sind die resultate entsprechend besser.
rapso schrieb:
Von der Zeit zur Fehlersuche (uihhhh, delete vergessen) und
zur Wartung der Programme reden wir hier ja nicht, da wären
es nochmal 10er Potenzen mehr, die Java schneller ist.so ein dummfug geht mir wiederrum auf den sack, als ob man irgend nem marketing geschwaetz glauben sollte als rational denkender entwickler. oder um es auf deine stumpfe art zu sagen: uihhhh, referenz vergessen.
Das sagt nicht das Marketing, sondern die Erfahrung.
dann hast du sehr wenig erfahrung wenn du noch kein programm mit gc gesehen hast das trotzdem nen memleak hat und alle 24h auf dem server neugestartet wird.
-
Diese sadisten vergleichen Prolog mit Perl? (http://shootout.alioth.debian.org/gp4/prolog.php) na zeigt ja nicht gerade von kompetenz 2 total unterschiedliche Paradigmen zu vergleichen...
-
Na immerhin liefern sie Zahlen. Es geht nichts über Benchmarking, auch wenn die Methode nicht perfekt ist.