C++ schneller als andere Sprachen?

Blue-Tiger

muemmel schrieb:

So schön komplett portable Programme sein mögen, aber Portabilität heißt unweigerlich IMMER auch eine Einigung auf den KLEINSTEN Nenner. Ob das immer im Interesse des Kunden ist???

Das sehe ich absolut nicht ein - in C oder C++ vielleicht (auch nicht, wenn du dir einfach angewoehnst multiplattform-Frameworks zu verwenden). Aber wenn du in Java oder Python entwickelst, ist das Ganze kein Thema. Und ich reduziere meine Moeglichkeiten dabei mitnichten auf den kleinsten Nenner, da das unterliegende Framework in der Regel Features, die auf einer Plattform nicht vorhanden sind, mit eigenen Mitteln implementiert. Da ist Portabilitaet kein Thema, sie ist impliziert.

asc

muemmel schrieb:

was ich immer noch nicht so ganz verstehen kann, ist das herumreiten auf Portabilität. Sicher, für manchen ist es wichtig, aber ich behaupte mal, daß 95% aller Programmierer nur für eine Umgebung coden.

Ja, sicherlich mag das stimmen. Aber schon einmal daran gedacht das dann irgendeiner aus der Höheren Etage dem Kunden verspricht das die Anwendung in Kürze auch für xyz verfügbar ist (So etwas in leicht entschärfter Form habe ich schon erlebt).

Okay, lassen wir das Thema Portabilität mal weg: Nenn mir bitte eine C++ UI-Bibliothek (Plattform sei erstmal egal) die mit relativ modernen C++ klarkommt, und wo man nicht dauernt zwischen Anwendungslogik und Oberfläche portieren muss. Zudem sei die Anforderung das man eine möglichst freie IDE-Wahl hat, und nicht auf irgendeine Bibliotheksspezifische auszuweichen.

muemmel schrieb:

Und was die Bandbreite von Win 3.1 bis Win Vista betrifft, wers braucht... Für die meisten Programme die heute noch entwickelt werden reicht es doch völlig aus, wenn die ab XP oder meinetwegen ab Win 2000 laufen.

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.

muemmel schrieb:

So schön komplett portable Programme sein mögen, aber Portabilität heißt unweigerlich IMMER auch eine Einigung auf den KLEINSTEN Nenner. Ob das immer im Interesse des Kunden ist???

Schon richtig, was mich aber auch auf einer Plattform stört wenn man unter C++ entwickelt, ist das man für die UI in der Regel noch ein paar Kompromisse machen muss. Nichts gegen C++, wenn man davon absieht (und von der fehlenden Binärkompatibilität) bin ich mit der Sprache voll zufrieden.

muemmel schrieb:

der will einfach daß jedes neue Programm genau so aussieht, wie die die er bisher von Windows kennt damit er sich zurechtfindet und sich nicht neu einarbeiten muß...

Dieser Satz hat ich schon so häufig in Konflikte mit meinen Chef gebracht. Da seine Interpretation von Oberflächenstandard dem von etwa 95% aller Windowsanwendungen zuwider läuft.

cu André

muemmel

Hi André,

vielleicht sollte Dein Chef mal darüber nachdenken, wer den "Spaß" wirklich bezahlt, er oder der Kunde.

Daß Chefs immer zu großen Versprechungen neigen hab ich leider selbst erlebt... (natürlich können wir auch...).

Meist wird dann viel Arbeit in eine ganz kleine Sache reingesteckt, die man unter Umständen mit ienem Bruchteil an Aufwand gleich mal in Excel machen könnte...

Es gibt immer noch die alte Regel, daß 80 % der Wünsche mit 20 % vom Aufwand befriedigt werden können. Für die restlichen 20 % benötigts dann 80 %, also ein mehrfaches...

Sicher ist Kunde König, aber man muß immer unterscheiden, zwischen Brot- und Butter-Software die für die Masse der Kunden die die Geldbüchse nur ganz wenig aufmachen ist, und handgeschmiedeter Edelsoftware für die Goldcard-Kunden die dann aber auch adäquat dafür zahlen müssen.

Oft ist es aber so, daß die Masse Dinge bezahlt, die sie nie im Leben braucht, weil ein paar ganz wenige Sonderwünsche haben und glauben, daß die mit ihrem 08/15-Einkauf auch abzudecken sein müssen.

Lieber ein paar Mäkel-Kunden verlieren, aber dem Rest eine soliede und preiswerte Lösung anbieten.

Was die IDE und das GUI betrifft, so ist CodeGears VCL sicher nicht optimal, zumals ja eine in Pascal geschriebene ist aber ich hab mich daran gewöhnt und kann bisher ganz gut damit leben.

Gruß Mümmel

Nenn mir bitte eine C++ UI-Bibliothek (Plattform sei erstmal egal) die mit relativ modernen C++ klarkommt, und wo man nicht dauernt zwischen Anwendungslogik und Oberfläche portieren muss. Zudem sei die Anforderung das man eine möglichst freie IDE-Wahl hat, und nicht auf irgendeine Bibliotheksspezifische auszuweichen.

gtkmm + Bakery ist z.B. so ein Kandidat, kannst du mind. mit MSVC und GCC benutzen... IDE ist dir somit auch frei gestellt.

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 Arsch in der Hose. Da ruft der Kunde am Freitag an, will was zu Montag haben, und der Chef sagt "Klar, machen wir!". Hallo??? Und der kleine Angestellte darf das Wochenende durcharbeiten. Warum? Weil der Chef keinen Mumm hat, dem Kunden zu verklickern, das es so einfach nicht geht oder der ordentlich für die Wochenendarbeit draufzahlen muß!

Genau das gleiche, wenn der Kunde vielleicht von Uralt-Systeme einsetzt aber Ansprpüche stellt, die man nur mit modernen Systemen kostengünstig erfüllen kann. Entweder verklickert man das dem Kunden, oder man hält die Hand auf für den Extraaufwand.

Übrigens haben diese Probleme nichts mit C++ speziell zu tun. Unser Kunde setzt Java 1.4 ein. Und nein, wir dürfen keine Java 1.5 Features einsetzen. Wenn der Kunde Features haben will, die nur mit 1.5 bereits vorhanden sind, sagen wir "Kostet jetzt aber natürlich extra-Arbeit und somit mehr Geld." Aber hat der Kunde selber schuld, wenn er nicht auf 1.5 umsteigt. Gut für uns, die Arbeit geht uns nicht aus.

asc

muemmel schrieb:

vielleicht sollte Dein Chef mal darüber nachdenken, wer den "Spaß" wirklich bezahlt, er oder der Kunde.

Mir egal *aufkalenderschau*, noch 14 Tage dann war es das...

muemmel schrieb:

Es gibt immer noch die alte Regel, daß 80 % der Wünsche mit 20 % vom Aufwand befriedigt werden können. Für die restlichen 20 % benötigts dann 80 %, also ein mehrfaches...

Das Problem ist hierbei extremer. Wenn wir nur die Kundenwünsche betrachten würden, und dann erstmal 80% mit normalen Möglichkeiten umsetzen würden, wäre den Kunden schon mehr geholfen. Aber die Standardoptik von MS gefällt dem Chef nicht (Was dazu führt das man an der UI deutlich länger hängt als nötig, und sie danach aussieht... naja, jeder hat einen Eigenen Geschmack). Controls die sich Standardkonform verhalten (und ggf. da zugekaufte ActiveX, damit es "schneller" geht, auch nicht komplett änderbar sind, sollen grundlegend anders eingesetzt werden als geplant) werden nach dem Geschmack vom Chef mit seinem "Standard"-verhalten angepasst...

muemmel schrieb:

Sicher ist Kunde König, ...

Manchmal frage ich mich wie masochistisch oder abhängig Kunden von einer Software sein können, das sie alles mit sich machen lassen. Und das schlimmste ist wenn man dann einen Kunden weitervermittelt bekommt, der etwas von der Bedienung nicht versteht, und man ihn nur an den Chef weiterleiten kann, da man selbst nicht versteht warum man es so, und nicht wie in anderen Anwendungen lösen sollte... (Wenn man z.B. etwas in eine Anwendung einbaut, würde ich mich in erster Linie grob an dem orientieren, was der Kunde schon kennt bzw. was auf dieser Plattform der Standard wäre [zumindestens von der Bedienung her]).

muemmel schrieb:

Oft ist es aber so, daß die Masse Dinge bezahlt, die sie nie im Leben braucht, weil ein paar ganz wenige Sonderwünsche haben und glauben, daß die mit ihrem 08/15-Einkauf auch abzudecken sein müssen.

Ich würde sagen bei uns ist 80% Chefwunsch, vom Rest 80% Kundenwunsch... Das der Kunde dann effektiv noch deutlich weniger erhält als geplant ist logisch (Oder man soll ein komplexes Modul entwerfen, und bekommt dazu ganze 2(!) Sätze an Informationen. Wenn man dann ständig nachfragt heißt es das man nicht selbstständig arbeitet - wenn man aber sich an bestehenden Orientiert ohne nachzufragen wird am Schluß alles auseinander gerissen).

muemmel schrieb:

Lieber ein paar Mäkel-Kunden verlieren, aber dem Rest eine soliede und preiswerte Lösung anbieten.

Lieber Kunden haben als keine Kunden haben.

muemmel schrieb:

Was die IDE und das GUI betrifft, so ist CodeGears VCL sicher nicht optimal, zumals ja eine in Pascal geschriebene ist aber ich hab mich daran gewöhnt und kann bisher ganz gut damit leben.

Ich muss gestehen das ich die VCL trotz aller Nachteile auch nicht schlecht finde. Ohne die Extremsonderwünsche meines Chefs wäre das auch DIE Umgebung für unsere Firma (statt dessen setzen wir auf Compiler die seit 10 Jahren nicht mehr supportet sind).

Nur wegen der vielen Sonderwünsche wäre für unsere Firma tatsächlich .Net und WPF besser (1. kann man dann das Aussehen der Controls mit einheitlichen Templates versehen, 2. Ist die Oberfläche skalierbar und 3. kann man dann auch Wünsche wie Checkbuttons in Karteireitern, Buttons und andere Elemente in Treeviewelementen etc. ohne riesigen Aufwand einbauen).

cu André
P.S. Bevor ich zu meiner jetzigen Firma kam, die ich nun nach 4 Jahren verlasse dachte ich, ich hätte Chaosprojekte gekannt. Jetzt muss ich sagen das ich mich zurücksehne an die vorherigen Firmen die wenigstens etwas Kundenorientierter, Standardkonformer und vor allem auch mit zumindest maginaler Dokumentation gearbeitet haben (Ich schätze das 95% der Dokumentation zu der Software von mir stammt, und das auch nur dort wo ich etwas Zeit hatte - und 99% aller Dokumentation dürfe rein im Sourcecode sein).

Konzepte, kann man das essen?

asc

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é

frenki

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...

DEvent

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/coolapps

Oder Java: http://java.dzone.com/tips/ten-amazing-java-applications

Wenn man das richtige Framework hat ist Plattformunabhaenigkeit geschenkt.

muemmel

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

DEvent

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?

muemmel

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.

rapso

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?