Das beste aus beiden Welten: aus Java die Sprache und Platform, AWT,SWT,Swing kann man dann in die Tonne treten und man muss sich nicht mehr mit C++ rumplagen wenn man Qt nutzen will.
Langsames Java-GUI ist ein Problem der Implementation. Die bei meinem Arbeitgeber implementierte Applikation /Swing) steht in nichts einer Applikation nach, die in einem heavyweight UI-Framework implementiert ist, nach. Trotzdem bin ich kein Freund von Swing, denn da keine native Controls verwendet werden funktionieren einige Dinge nicht, nämlich alle Funktionen, die COntrols einer Applikation erkennen müssen (z.B. komfortable Handschrifterkennung)
> steht in nichts einer Applikation nach, die in > einem heavyweight UI-Framework implementiert ist
Und ich dachte immer, Swing wäre Heavy-Weight (-: Ich kenne kaum ein anderes Toolkit, dass die einfachsten Dinge dermaßen kompliziert macht. Ich sag nur Gridbag. Okay, ich bin wahrscheinlich verwöhnt, und Motif/MFC etc.-Veteranen werden hier laut auflachen.
Zur Geschwindigkeit: Was sind denn die Swing-spezifischen Dinge, auf die man achten muss, damits fixer wird? Einen Layoutmanager nehmen und Widgets reinhauen, wo kann man dabei groß rumschrauben?
> Und ich dachte immer, Swing wäre Heavy-Weight (-:
Tja, Verwechslung ;-)
Angeblich haben sie einige Java-typischen Prüfungen mit Reflection umgangen. So ganz ungefährlich ist das natürlich nicht. Was sie sonst noch machen, müsste ich den GUI-Programmierer fragen. Der ist auf jedenfall mit Swing glücklich, ich eher nicht (QT-verwöhnt).
> Angeblich haben sie einige Java-typischen > Prüfungen mit Reflection umgangen. So ganz > ungefährlich ist das natürlich nicht.
Und dann sag nochmal jemand, C++ wäre mehr "Gefrickel" als Java. Wenn man rumfrickeln muss, damit ein _GUI_ -_Toolkit_ performant wird, läuft irgendwas falsch mit dem Toolkit.
Ich bin kein Freund von Swing, soviel dazu! Die Behauptung dass Swing generell langsam ist, ist falsch (im übrigen tat sich viel von bei den Versionssprüngen 1.3->1.4 und 1.4->1.5). Mit Reflection an den entscheidenden Stellen kommt man mit C++ seitens Geschwindigkeit ins Schwitzen. Hierzu hatte ich einige Gespräche mit unseren Java-Entwicklern geführt.
Die Aussage ist unqualifiziert, da die Begriffe nur rein stereotypmässig verwendete sind. Somit hat sich der Autor disqualifiziert, unabhängig von dem, was aus sagen wollte.
Naja, momentan entwickle ich in Java, vermisse jedoch das ein oder andere aus der C++-Welt. Das Problem ist nur: Woher bekomme ich so etwas änliches wie JBOss, Geronimo etc? Bis jetzt habe ich nichts gefunden. Da ein Container ab EJB 3.0 praktisch nicht mehr um Bytecodemanipulation herumkommt, wird es schwierig, so etwas für C++ zu entwickeln. Die Maschinenabhängigkeit dürfte hiermit ein grösseres Problem sein, denn immerhin war es (irgendwie) möglich, eine Software so zu entwickeln, dass sie auf einer Plattform lieft, liegt jedoch ein wesentlicher Teil der Funktionalität in der Manipulation des Binärcodes, dürfte dies ein definitiver Vorteil bytocodebasierter Sprachen sein, der kaum wettzumachen Sein wird.
Konkreter Einsatz der Bytecodemanipulation liegt in der AOP und ich meine auch im Umgang mit Anotations.
hast du zu dem konkreten einsatz auch nen konkretes beispiel? ;) ich bin nich so der java enterprise entwickler und die ganzen buzzwords find ich eh doof
So ähnlich sollte Applikationsentwicklung funktionieren in C++:
Serverseitig wird nur eine Bibliothek implementiert. Innerhalb dieser werden die Eigenschaften der entsprechenden Klassen spezifiziert, z.B. Entität (Representant einer Informationseinheit z.B. in einer DB, gecached, wird freigegeben falls eine Zeit nicht mehr benötigt) oder auch andere (In EJB gibt es Entity-Beans, Session-Beans (zustandslos und zustandsbehaftet). Dabei interessiert mich bei CMP (Container managed persistance) nicht mehr, wie das Objekt in der Datenbank abgelegt wird, sondern anhand vom Code werden die Tabellen ideal angelegt. Auch die Instanzierung der Objekte ist völlig sekundär, das macht der Container, der das ganze viel allgemeiner und optimierter kann als ich. Punktum: Datenbankzugriff und Caching wird von einer Applikation gemanaged, die meine Bibliothek dynamisch nachlädt, sobald ich diese ihr zum Frass vorwerfe. Diese Bibliothek wird als serverseitige Applikation verstanden. Selbstverständlich kann man dem Container auch mehrere "Applikationen" zu Ausführung übergeben. In der EJB-Welt ist auch das Clustering gratis dabei, ich muss nichts dafür tun als das System richtig zu konfigurieren (!). Dazu gehört, dass Datenbankzugriffe nicht in meiner Applikation sondern im Container konfiguriert werden. Dies bedeutet, dass ein Name festgelegt wird, unter dem die gewünschte Datenbank angesprochen wird. Welche DB dahinter liegt, ist dem System (fast) egal. Der Vorteil ist die Betriebssicherheit (Entwicklung -> Integration -> Produktion, nur durch Transfer der Applikation von einem Container in den nächsten, Die Konfiguration bleibt unverändert, da sie nicht der Applikation zugehöirg ist sondern im Container erfolgt). Desweiteren ist der integrierte Namensdienst (JNDI) sowie der standardisierte Verzeichnisdienstzugriff sehr praktisch. Hiermit können auch Verzeichnis, NIS oder LDAP-Zugriffe durch den Container gemenaged werden.
Meiner Meinung nach ist C++ in einigen Dingen Java überlegen. Die Stärke von Java liegt jedoch nicht in der Sprache sondern in dem mächtigen Technologieportfolio, das auch für mich anfangs nur aus böhmischen Dörfern bestand.
Auf AOP (aspektorientierte Programmierung) bin ich oben noch nicht eingegangen. Dort werden Eigenschaften aus des Klassen ausgelagert, d.h. es werden Aspekte (technische Funktionalitäten) implementiert und daneben die eigentliche Applikationslogik. Den Klassen der Applikationslogik wird der jeweilige Aspekte (oder mehrere Aspekte) zugewiesen und der Aspektweber "webt" die technischen Eigenschaften zur Laufzeit in die Klassen ein. Dazu wird der Binärcode zur Laufzeit verändert. Bei C++-Programmierern dreht sich bei dem Gedanken der Magen um, in Java gibt es für solche Manipulationen fertige APIs, die das zuverlässig ermöglichen.
Templates sind ein bisschen wenig Munition um eine EJB-ähnliche Infrastruktur aufzubauen. AOP ist jedoch nicht mit Templates gleichzusetzen. Bei AOP werden die relevanten implementierten Methoden um Funktionalitäten an richtiger Stelle erweitert. Es handelt sich ausserdem leider um einen gewissen Bruch mit der OOP.
AOP mag ganz interessant sein für debugging und logging. In allen anderen Bereichen, bringt es jedoch mehr Verwirrung als Vorteile. Man stelle sich mal vor, man würde AOP ernsthaft weitflächig einsetzen und dann Quellcode vorgesetzt bekommen, desen Abarbeitungsreihenfolge und Logik sich maximal noch aus zusammengefassten Aspekten ergibt die sich zudem auch noch gegenseitig beeinflussen können und dass alles zudem noch in einer Art und Weise in der sich die dahinterstehende Logik nicht mehr durch studieren der Klassen erschließen läßt. Man bräuchte umfangreiche Diagramme die wiederspiegeln welche nicht direkt ersichtliche Funktionalität durch den Aufruf einer einfachen Methode angestossen wird und in welcher Reihenfolge. Wie diese Aspekte miteinander verpflochten sind und miteinander kommunizieren.
Das mit AOP ist nicht ganz richtig. Ich habe einmal in iX einen Artikel gelesen, wie man auch die elegant in C++ realisieren kann (mithilfe von Templates & Namespaces). Abgesehen davon gibt es AFAIK genau wie für Java speziell dafür ausgelegte Softwarepakete.
Für AOP gobt es AspectC. AOP ist jedoch nicht mein zentrales Problem. Einen Applikationsserver ähnlich JBoss oder Geronimo bräuchte ich. Seltsam, SOPE setzt z.B. auf Objective C anstelle auf C++. Gibt es dafür einen Grund, dass niemand so etwas für C++ anbietet? Ich habe nun etwas nachgefprscht und mich gefragt, wie sich so etwas implementieren liesse. Dabei bin ich auf zwei Problemfelder der C++-Welt gestossen: - Dynamisches Nachladen von Libraries zur Laufzeit: Dieses geht für C sehr gut. Für C++ ist dies umständlich jedoch irgendwie noch vernünftig machbar. Mit "new" geht jedoch nichts mehr, sondern man benötigt für alles eine Factory. Wenn jemand einen anderen Weg aufzeigen könnte, wäre das eine Dokumentation an geeigneter Stelle wert. - Fehlen von Reflection: Die Ansätze, welche ich gefunden habe, sind alle relativ ungeeignet, da sie zur Compilierzeit ablaufen, d.h. die schlussendlich verwendeten Klassen müssen bekannt sein. RTTI hilft nicht weiter, da gerade auf einen bekannten Klassentyp hin untersucht werden kann. De Forderung ist jedoch, dynamisch Objekte zu erzeugen, deren Klassen mir bei der Entwicklung nicht bekannt waren sondern nachträglich dem System zugeführt wurden (binär!) durch Analyse der Klassenstruktur. ANgeblich gäbe es eine Lösung Reflexion vom Cern, leider zeigen alle Links ins leere und ich finde nichts weiteres dazu.
Vermutlich hat Objective C diese Probleme nicht, andererseits ist es auch nicht sehr viel verwendet und in dieser Nische will ich nichts programmieren. Ich habe deshalb SOPE auch nicht mehr näher untersucht, ob es den Anforderungen sonst theoretisch genügen würde.
C++--? Wäre das dann nicht C? Oder C-1=B? Ist das überhaupt zulässig?
Zu Java: Manches in Java ist schon deutlich eleganter als in C++. Polymorphie z.B. Die API mag ich auch, jedenfalls die grundlegenden Klassen. Swing ist allerdings großer letzte Mist. In vielen Bereichen wiederum gibts gute libs, die meistens ein halbwegs gutes Design haben und brauchbar dokumentiert sind. Javadoc als Konvention hat schon Vorteile.
Was noch stört: Dass String als Referenzen durch die Gegend geschoben werden; dass ich keine Parameter als const deklarieren kann. Die JAR-Hell, sobald die verwendeten Libs verschiedene Versionen irgendwelcher anderen libs benötigen.
Serverbasiertes würde ich jederzeit in Java schreiben, für Desktop-Anwendungen kam es bisher nicht in Frage... Mal sehen ob Jambi daran was ändert.
Eine Stringvariable, die als final deklariert wurde, kann nicht wieder geändert werden. Bei einem String-Objekt gilt das sowohl für die Referenz, als auch für den Inhalt, weil ein String in Java immutable ist. Damit hat man definitiv eine Konstante.
ok string war nen schlechtes beispiel,da die in java ja eh konstant sind... java: class Foo { public int a; } final Foo f; f.a=5; <-- ok. f=f2; <-- nee c++ class Foo { public: int a; }; const Foo* f1;Foo* const f2; f1->a=5; <-- neee f1=blubb; <-- ok. f2->a=5; <-- ok. f2=blubb; <-- neee
Öffentliche Eigenschaften sind eh schlechter Stil. Wenn du die Eigenschaften als private deklarierst, könnte man das Verhalten in Java über eine Proxy-Klasse simulieren.
Von Anonymous Coward am So, 30. Juli 2006 um 11:47 #
Naja, wenn deine setX/getX-Methoden nichts anderes machen als this->X=X bzw. return X ist das IMHO auch nichts anderes als eine öffentliche Eigenschaft.
Zunächst ist das richtig, man kann setter und getter aber später ändern, wenn es nötig wird (irgendwelche checks hinzufügen, werte aus der datenbank laden etc.). Die Schnittstelle bleibt praktischerweise unverändert. Verwendet man öffentliche Attribute, kommt man um eine Änderung der Schnittstelle nicht herum.
char*? Grusel. Da ziehe Javas String-Klasse dann doch vor. Ich meine eine vernünftige String-Klasse, wie QString. Wer will, darf natürlich auch GLib::ustring oder std::string (das aber bitte nicht für GUI-Anwendungen) benutzen.
"In a perfect world the C++ Standard Library would contain a UTF-8 string class. Unfortunately, the C++ standard doesn't mention UTF-8 at all. Note that std::wstring is not a UTF-8 string class because it contains only fixed-width characters (where width could be 32, 16, or even 8 bits)."
ich wuerde auch keinen utf-8 string wollen,O(n) zeichen zugriff,nein danke... also richtig ist das ISO C++ nichts von unicode weiss,richtig ist aber auch das es seit C99 __STDC_ISO_10646__ gibt,was von der implementierung definiert wird um anzuzeigen das wchar_t unicode (also wohl UCS-4) ist.
also mein wstring ist ucs-4,und deiner?
ganz nebenbei ist eigentlich total egal welche kodierung wchar_t hat,es ist jedenfalls garantiert das es jedes zeichen des systems aufnehmen kann. (nein msvc ist in diesem punkt nicht konform)
> ich wuerde auch keinen utf-8 string wollen,O(n) zeichen zugriff,nein danke...
Aber durchgängig 4 bytes pro zeichen ist besser? UTF8 spart hier immerhin, wenn ASCII-Zeichen verwendet werden. Kommt natürlich immer auf die Anwendung an, aber ich brauche dann meistens doch eher nur sequentiellen zugriff auf die zeichen in einem string. und das lässt sich ja hübsch optimieren (in der String-Klasse gekapselt).
Wenn man weiß, daß man nur ASCII oder Latin1 Zeichen hat, zum Beispiel weil es interne Identifier sind, kann man natürlich für diese einen normalen std::string nehmen.
Ein Random Access Stringtype hat aber meisten bei der Textbearbeitung Vorteile gegenüber einem mehr oder weniger sequentiellen Typ. Vermutlich aus diesem oder ähnlichen Gründen sind daher auch QString und java.lang.String intern 16-Bit Unicode
nur bloed das 16-bit zu wenig sind fuer unicode>=4.0 ;-) also kommt man bei 16 bit bei einer multiword kodierung raus (huhu UTF-16)....naja das passiert wenn man den standard zu genau fasst (huhu java...huhu 16 bit char *g*)
QT ist nicht nur eine bibliothek um grafische oberflächen zu erstellen, sie ist _weitaus_ mehr. aber um nicht noch mehr "komplexität" zu bekommen würd ichs begrüssen wenn sie grade den grafischen teil in swt implementieren würden. (ggf halt noch ein paar eigene klassen). das ist meiner meinung nach die perfekte vorlage dafür, einfach die jni klassen in qt implementieren und fertig, keine(bzw kaum eine) zeile javacode nötig und die grafischen "bindings" sind fertig.
QT ist der göttliche Massstab bei den GUI toolkits, da gegen ist natürlich alles andere Dreck. Dabei kann man auch mit Swing ganz gut arbeiten. Auch mal bedenken von wann das ist.
Die bereits vorhandenen Java-Bindings werden meines Wissens bei KDE entwickelt, aber wozu man nochmal Java-Bindings braucht Das würde mich allerdings auch mal interessieren.
Hier ein paar (z.T. ältere) Beiträge aus Richard Dales Blog (KDE-Bindings-Gott und QtJava-Autor), in denen es u.a. auch um die alten QtJava-Bindings und Jambi geht:
Super(so richtig vollmundig, also so: SSuuppeerr), genau darauf hab ich gewartet. Damit ich endlich in Qt programmieren und das Ganze mit dem Runtime von Java unter Gnome laufenlassen kann. Nochmals klasse.
Von Anonymous Coward am Sa, 29. Juli 2006 um 05:19 #
Unfug, von selber werden sich Applikationen auch in Zukunft nicht an irgendeinen Desktop anpassen, ausser vielleicht optisch. Viel wichtiger ist es, dass auch die Dialoge usw. sich an die UI-Richtlinien eines Desktops halten, und dafür kann ein Toolkit nicht sorgen. Ich kann mit gtkmm ein Programm schreiben, das sich wunderbar in KDE einpasst, und ich kann mit Qt eine Applikation schreiben, die sich an die GNOME Interface Guidelines hält. Ich könnte das auch mit Swing oder $insert_random_toolkit_here tun, es ist abgesehen von der (unwichtigen) Optik völlig egal...
> Unfug, von selber werden sich Applikationen auch in Zukunft nicht an irgendeinen > Desktop anpassen
Ich warte noch auf ein HIG-Abstraction-Layer ;-)
> Ich kann mit gtkmm ein Programm schreiben, das sich wunderbar in KDE einpasst, und > ich kann mit Qt eine Applikation schreiben, die sich an die GNOME Interface > Guidelines hält.
Das wird bei der Verwendung von Datei- oder Druckdialogen aber schwierig, es sei denn, du willst die im anderen toolkit reimplementieren. Aber Portland soll ja hier Abhilfe schaffen.
> Ich könnte das auch mit Swing[...]
Gerade bei Swing habe ich manchmal meine Zweifel, dass man da mit vertretbarem Aufwand etwas brauchbares entwickeln kann. Manche Standardwidgets sind einfach grottig. Warum kann man z.B. bei labels kein Wordwrap einstellen? Zu große Toolbars (ok, schlechtes Design der Anwendung) werden nicht vernünftig gehandlet, etc. pp.
> es ist abgesehen von der (unwichtigen) Optik völlig egal...
So unwichtig ist die auch nicht. Swing- oder Motif-Anwendungen verursachen Augenkrebs. Aber sie wird oft als einziges Kriterium für Integration und Konsistenz genannt, und das ist natürlich Quatsch.
Von Peter Paul and Mary am Sa, 29. Juli 2006 um 01:54 #
was zusammen gehoert.
Auch wenn ich jetzt einigen auf die Fuesse pette. Java und Qt sind ein irrtum! Und ich bin keine Anhaenger der C - GTK+ Fraktion! Java und Qt (auch wenn es sich bessert) sind einfach zu abstrakt im Design. Abstraktion ist wichtig um die lesbarkeit und wartbarkeit von Code zu verbessern, nur zu hohe Abstraktion fuehrt zu einem sich potenzierenden Leistungsverlust und zur Unlesbarkeit. In unserer Abteilung (Forschung/Entwicklung bei XX ) kamen immer wieder die gleichen Fragen auf - warum muss ein "simpler Typ" ein Object sein? (speicher- rechenzeitverschwendung) - warum muss man durchreichen fuer exeptions schreiben? (rechenzeitverschwendung) - warum kann ich eine Datei nicht zeichenweise auslesen sondern erst komplett in den Seicher laden bzw. habe keine Kontrolle wie das Framework es anstellt? (kontrollverlust) ... Qt hat bei uns den "ruf" Javadesign in C++ zu provozieren. Hart ausgedrueck, ist aber so. Ich moechte jetzt keinen Flamewar vom Zaun brechen, nur fuehren Qt und Java zu schlechten Programmierstil. Es wird nicht mehr auf die Speicherverwaltung geachtet (in Java nicht zu umgehen aber Qt, bitte). Es wird alles moeglich in den Speichergeladen und ewig dort gehalten. Es wird mit Objecten um sich geworfen als waehre es Fallobst. Sicherlich kann man auch in Java bzw. mit Qt "sauber" Coden wenn man es moechte. Unsere Erfahrungen gehen aber einhellig dort hin das es fuer nicht "wichtig" gehalten wird. Auf Fragen in den einschlaegigen Mailinglists bekommt man sehr haeufig die Antwort: "Der GC macht das schon!". Sowas spricht nicht fuer die Java Qt Fraktion!
Ein paar kleine Ueberzeugungen von uns: - Code ist fuer Coder da - wer Coden will sollte eine Vorstellung haben wie der Speicher und Rechner arbeitet (PDA, PC etc. im Schema immer gleich) - Coder wissen was ein int ist und wie man mehrere Zustaende in einem int speichern kann - Coder wissen wo der this-Zeiger herkommt und warum er da ist - wer nicht rechnen kann sollte keine Programme fuer Rechner schreiben (nicht ganz so hart gemeint aber das ( 2 + 4 ) gleich ( 2 bitor 4 ) ist sollten Coder schon wissen) - wenn ich ein Muster in einer Datenmenge suche kann dieses durch maximal zwei durchgaenge (meist schon im ersten) gefunden werden - wenn ich ein Glied aus einer Kette zerstoeren moechte muss ich erst den "next-Zeiger/Referenz" umhaengen um nicht die Kette zu zerstoeren - AlgoDat heisst: die Breitensuche verstanden zu haben
Klar sind Sprachen toll mit dem jeder seiner Mutter ein Adressbuch schreiben kann. Aber im Produktivbereich sollte Fachwissen nicht ein Framework mit zu strenger "Aufpassermanier" den Ton angeben.
Auch wenn sich hier einiges "getrollt" anhoert oder/und nach einem Flameaufruf, das sollte es nicht sein. Nur mal ein Statment von einer Gruppe die sich seid einigen Jahren mit den Vor- und Nachteilen bestehender "Loesungen" befasst.
otc Peter Paul and Mary
P.S.: Seid einigen Monaten wird bei uns mit "D" von Digital Mars rumgespielt. Sieht sehr sehr gut aus, vorallem fuer sein alter.
> warum muss ein "simpler Typ" ein Object sein? (speicher- rechenzeitverschwendung) Darf man fragen wovon du sprichst? Ist QString für dich ein simpler Typ? Wo wird Rechenzeit verschwendet?
> warum kann ich eine Datei nicht zeichenweise auslesen sondern erst komplett in den Seicher laden bzw. habe keine Kontrolle wie das Framework es anstellt? (kontrollverlust)
Muß man nicht. Im Übrigen kann man von Klassen erben und Algorithmen reimplementieren die einem nicht gefallen. Aber das hättest du auch wissen können.
> Code ist fuer Coder da Autsch. Klingt nach Frickelfraktion.
> Auch wenn sich hier einiges "getrollt" anhoert Oh ja.
> Nur mal ein Statment von einer Gruppe die sich seid einigen Jahren mit den Vor- und Nachteilen bestehender "Loesungen" befasst. Den Beweis bleibst du schuldig. Viel erzählen kann jeder.
Von Anonymous Coward am Sa, 29. Juli 2006 um 05:36 #
Zunächst mal hat Qt überhaupt keinen Garbage Collector. Das einzige, was entfernt daran erinnert, ist dass ein Widget automatisch die Destruktoren aller Kind-Widgets aufrufen wird, was ja auch sinnvoll ist. Was die Speicherverwaltung angeht kann man nur sagen: Ein GC arbeitet nunmal zuverlässiger als jeder Programmierer, wieso sollte man sich also (außer im Echtzeitbereich und bei extrem geschwindigkeitskritischen Applikationen (die man wohl eh nicht in Qt schreiben würde)) noch mit so eine Kram herumschlagen? Dafür gibt es keine logische Erklärung (außer einigen Programmierern die sich dadurch etwas beweisen müssen, dass sie ihren Speicher selber sauber halten).
Was Du und deine Firma offensichtlich nicht verstanden haben, ist, dass Einfachheit und Abstraktion die einzigen Mittel sind, um immer komplexer werdende Applikationen zu bewältigen - man muss sich von Sachen wie Speicherverwaltung usw. freimachen, um sich um die wichtigen Dinge zu kümmern. Es heißt ja nicht umsonst, dass ein Informatiker zu quasi jedem nichttrivialen Problem erstmal eine neue Sprache entwickelt :o). Ich will jetzt nicht sagen, dass Java die Lösung aller Probleme sei (allein weil es nicht frei ist, ist es für mich keine Alternative), aber Java, C# usw. zeigen doch eindeutig, wohin der Trend geht.
> außer im Echtzeitbereich und bei extrem geschwindigkeitskritischen Applikationen > (die man wohl eh nicht in Qt schreiben würde))
Gibt es überhaupt Applikationen mit grafischer Oberfläche, die Geschwindigkeitskritisch sein müssen? Abgesehen von reinen 3d Anwendungen fällt mir da nichts ein.
So schnell wie der Rechner rechnet, kann der Benutzer gar keine "echtzeit GUI" bedienen!
Was ich damit sagen will. Wenn ein Arbeitsprozess etwas in Echtzeit machen soll, dann ist die GUI von dem Echtzeitkern getrennt. Die GUI dient lediglich zur Ansteuerung und Statusabfrage des Echtzeitprozesses/-kerns und mir ist keine Arbeitsprozess bekannt, dessen Statusabfragen im ns Bereich garantiert werden muß! Denn so schnell kann, wie schon gesagt, kein Mensch sehen, erkennen und handeln.
Ich sehe daher also kein Problem, für eine Echtzeitanwendung QT als GUI zur Ansteuerung zu verwenden.
Nenne mir bitte mal einen Anwendungsfall in dem eine GUI (also so eine mit Buttons, Fenstern und Co) in quasie Echtzeit aktualisiert werden muß.
>Gibt es überhaupt Applikationen mit grafischer Oberfläche, die > Geschwindigkeitskritisch sein müssen?
Immer dann, wenn man in kurzer Zeit viele Daten verarbeiten muss, und der Benutzer erwartet, dass das Ergebnis möglichst schnell angezeigt wird. In einem Mail-Client z.B., wenn man tausende Mails nach irgendwas filtern möchte. Aber selbst da ist es kaum sinnvoll, deshalb Abstraktion und gutes Design aufzugeben, weil 95% der Anwendung nicht geschwindigkeitskritisch sein werden. An den 5% kann man noch gesondert rumschrauben. Und Qt ermöglicht genau das, Abstraktion wo möglich, low-level-Optimierung wo nötig.
> Immer dann, wenn man in kurzer Zeit viele Daten verarbeiten muss, und der Benutzer erwartet, > dass das Ergebnis möglichst schnell angezeigt wird.
Das ist doch Unsinn, dann muß die Anwendung lediglich möglichst schnell sein, aber Echtzeitfähig, daß muß sie definitiv nicht sein.
Echtzeitfähig ist z.B. wenn ein Computer ein Stück Metall zwischen zwei Magenten genau in der Mitte halten soll. Da ist Echtzeitfähigkeit im Nanosekunden bereich notwendig. Aber definitiv nicht um so eine Liste darzustellen.
Unter "geschwindigkeitskritisch" verstehe ich auch "möglichst schnell", also nicht nur harte Echtzeit. Irgendwo ist halt auch bei einer UI-Anwendung die (subjektive) Grenze erreicht wo eine Anwendung unbrauchbar wird.
Oft ist ja die Argumentation: "Geschwindigkeit bei GUI-Anwendungen ist fast egal, so schnell kann der User ja eh nicht klicken". Wenn aber pro Klick viele Daten angezeigt werden müssen, dann muss das List widget eben doch schnell sein.
Auch stelle man sich mal Software wie Blender oder Gimp in Java vor. Muss auch nicht umbedingt sein, daß der Rechner anfängt zu swappen, wenn man einen Webbrowsers und einen Newsreaders gleichzeitig laufen lassen will. Da lob ich mir meinen emacs
>In unserer Abteilung (Forschung/Entwicklung bei XX;) ) kamen immer wieder die gleichen > Fragen auf >[simple types als Object] >[Exceptions] >[Datei laden]
?? die simple types sind in Java keine Objekte. es gibt auch entsprechende klassen, aber die muss man ja nicht benutzen (außer in containern).
> "Der GC macht das schon!". Sowas spricht nicht fuer die Java Qt Fraktion!
Ich weiß nicht, was das jetzt mit Qt zu tun hat. Dort werden nur child widgets gelöscht, wenn das parent widget gelöscht wird. Das wars mit GC. Bist du sicher, dass du Qt nicht mit Swing verwechselst?
> Code ist fuer Coder da
Ist das nicht eine Tautologie?
> das ( 2 + 4 ) gleich ( 2 bitor 4 ) ist sollten Coder schon wisse
Das braucht man bei Desktopanwendungen eher selten.
> - wenn ich ein Glied aus einer Kette zerstoeren moechte [...]
Ja, und? Machen die Container-Klassen von Qt das falsch? Und wer will überhaupt selbst Listenklassen implementieren?
> Aber im Produktivbereich sollte Fachwissen nicht ein Framework mit zu > strenger "Aufpassermanier" den Ton angeben.
Ohje, C-Hacker? Die haben auch immer Angst davor, dass ihnen jemand "die Kontrolle wegnimmt", bei Dingen, die absolut performance-unkritisch sind. Dafür bauen sie dann Buffer Overflows und wasweißich noch für Bugs ein, weil sie es mal wieder selbst schlecht lösen müssen, statt eine Bibliothek zu nehmen. Und in 95% der Fälle ist erhöhte Abstraktion nützlich, erhöht Lesbarkeit, reduziert die Komplexität und man vermeidet Bugs. Außerdem ist man auch noch produktiver. An den restlichen 5% will man dann natürlich rumschrauben können. Da ist man dann bei C++ gegenüber Java im Vorteil.
Und Qt hat keine Aufpassermanier, es ist einfach eine gut designte Bibliothek. Zur Effizienz usw: Wir reden von Desktopanwendungen. Da muss man oft nur an recht wenigen Stellen optimieren. Meistens dann, wenn man irgendwo viele Daten verarbeiten und bzw. anzeigen lassen will.Und das sollte man nicht auf Verdacht tun, sondern mit Profiling-Ergebnissen. Sonst kommt nur unleserlicher, "optimierter" Code bei raus, bei dem 99% der "Optimierungen" überhaupt keinen spürbaren Effekt haben. Man kann nur immer wieder auf den Artikel Optimization is your worst Enemy verweisen.
> Seid einigen Monaten wird bei uns mit "D" von Digital Mars rumgespielt.
Das stimmt wohl für euren Einsatzbereich. Sieh dir jedoch mal im Bankenumfeld an, was bei dem Fachwissen in prozedualer Entwicklung herausgekommen ist: - vertikale Applikationen: von UI bis DB in einem Block durchprogrammiert. Keine Verallgemeinerung, keine Wiederverwendung möglich - undurchsichtige Verwebung der Applikationen: den Umstand, dass die Applikationen keine Informationen untereinander austauschen können, wurde mit spezifisch implementierten Schnittstellen abgeholfen. - Zahn der Zeit: Die Applikationen wurden erweitert um Funktionen, an die man bei der Implementation nicht dachte, mittlerweile gab es Stellenwechsel, da die Sprache nicht aufpasst und die neuen Mitarbeiter nicht alles Wissen, was der Vorgänger sich gedacht haben, gibt es neue, ganz perfide Fehler, nach denen wochenlang gesucht werden kann. - Wartbarkeit -> 0: Ergibt sich aus den oben genannten Punkten. - Fachbereichsknowhow in sterbender IT vergraben: Im Rahmen der Rationalisierung wurde das Fachwissen, welches automatisierbar ist, in IT gegossen. Damit wurden die IT-ler zu den Fachspezialisten, neue Mitarbeiter sind jedoch nicht als solche ausgebildet. Die bisherigen Technologien ermöglichten nicht, sowohl die Automatisierung als auch das verbleiben des Fachwissens im Fachbereich zu vereinen. In der Realität wusste in der Vergangenheit der Banker genau, wie die Abläufe funktionieren und er wusste was er wollte, heute kann man ihn fragen und er bleibt immer wage, da er die Abläufe selbst nicht versteht ("das müsst doch ihr wissen"). Wer hat jetzt die Bankfachausbildung genossen? . Die Programme vor 10-20 Jahren, sonst weiss niemand mehr Bescheid!
Ein Problem ist keines, wenn ein anderes um Grössenordnungen mehr schmerzt. Deshalb ist Speicherbedarf kein Problem, auch wenn es technich gesehen eines ist. Neuentwicklung verkorkster Applikationen oder Bereinigungen kosten Millionen!!! Die Löhne und Implementierungszeiten sind das Problem und alles, was den Entwicklern Arbeit abnimmt, ist willkommen (ich bin nicht für niedrigere Löhne!). Die IT-Landschaft bei den Banken ist in einem desolaten Zustand (europaweit) und ein Aufräumen mit den traditionellen Methoden ist in einer "elapsed Time" von 10 Jahren möglich, mit Sprachen penetranter Eigenschaften für Programmierer technischer Detaillösungen oder PDA-Software sind genau hier die Lösung (Beispiele für erfolgreiche, stabile und flexible Umsetzung in einem Bruchteil der Zeit, und damit Kosten, sind mir bekannt).
Schlussfolgerung: - In vielen technischen Bereichen, insbesonderewenn garantierte Reaktionszeiten verlangt werden, hat Java nichts zu suchen. Manchmal ist sogar noch Assembler angesagt. - In Dienstleistungsbereichen ist Java die erste Wahl.
>- In vielen technischen Bereichen, insbesonderewenn garantierte Reaktionszeiten verlangt werden, hat Java nichts zu suchen. >Manchmal ist sogar noch Assembler angesagt. Man kann Java sehr wohl echtzeitfähige Anwendungen schreiben nur auf denn Garbage Collector muss man dann eben verzichten. Es gibt übrigens auch Java-Assembler, aber das nur so am Rande. Assembler hat in der Anwendungsentwicklung gar nichts verloren, sondern nur in der Treiber-Entwicklung. Schön wenn man sich erst über vertikale Applikationen beschwert und wenige Sätze später nicht mal zwischen Treiber- und Anwendungsentwicklung trennen will, das gibt natürlich 1a-Reusability
Ohne Garbage-Collector wird es besser, das stimmt. In freier Wildbahn ist das jedoch kaum anzutreffen. In der Anwendungsentwicklung kann es notwendig sein, einen Teil hochoptimiert (bitte als Library) in Assembler zu implementieren. Ein ehemaliger Entwickler aus unserem Konzern hat jetzt gerade so ein Problem, dass er durch Verwendung der SSE2-Erweiterungen erhebliche Performancevorteile selbst gegenüber C herausholt (Verwendung des Intel-Compiler, der das auf dem Papier eigentlich ideal verwenden sollte). Ein messbarer Faktor von 4 in der Ausführungsgeschwindigkeit erlaubt an der performancerelevanten Stelle den punktuellen Einsatz von Assembler. Ob das Sprachengemisch schön ist, ist ausnahmsweise untergeordneter Priorität (es geht am Schluss schliesslich darum, ob der Cluster aus 5 oder 20 Maschinen besteht!).
Warum Java-Anwendungen ohne Verwendung eines Garbage-Collectors nicht anzutreffen sind, ist naheliegend: Kein Java-Entwickler rechnet damit und der nächste programmiert unter an Sicherheit grenzender Wahrscheinlichkeit ein Memory-leak ein.
>nicht ganz so hart gemeint aber das ( 2 + 4 ) gleich ( 2 bitor 4 ) ist sollten Coder schon wissen Der Coder sollte aber auch wissen, dass 2 + 4 bereits vom Compiler zusammenaddiert wird.
Sorry, nichts gegen eure Überzeugungen, aber was du das aufzählst ist primitivstes Grundwissen was wohl jeder Programmierer beherrscht (und zu mindest in meinem Info-Studium schon im ersten Semester gelehrt wurde - OK ist schon 10 Jahre her aber ich denke da hat sich nicht soviel geändert).
Ansonsten gibt dein Posting nicht wirklich viel her: - Was bezeichnest du als primitive Typen? char, int etc. sind auch in Java und C++ einfache Typen. - Bzgl. Dateien: Kann es seien das du hier versuchst das Streaming zu kritisieren? Wenn ja, ganz schlechter Versuch! - Qt hat keinen default GC. dazu werden unter C++ zusätzliche Bibliotheken benötigt. - Wenn du in C++ keine Exceptions verwenden willst, lass es doch einfach!
Kann es sein, das du den Unterschied zwischen prozeduralem und objektorientiertem Denken nicht so ganz verinnerlicht hast, oder wie soll ich deine Kritik bzgl. Javadesign interpretieren?
Gerade im Produktivbereich kann ein Framework mit strenger Aufpassermanier viele Fehler vermeiden helfen. Schließlich haltet ihr euch ja auch freiwillig an best. Coding Guidelines (zumindest hoffe ich das).
Wenn ich die Aussage(n), die US-Tastatur und die Namen zusammenziehe kann ich mir ziemlich genau vorstellen welche Gruppe hier gepostet hat Schoen das ihr hier doch mal vorbeischaut, wenn auch auf provokante Art.
Und wenn ihr die Diskussion schon nach aussen tragt. - Code ist fuer die da die ihn lesen koennen und/oder die lernen wollen ihn zu lesen und zu schreiben! - jeder Profi-Hacker weiss wie Speicher und Rechner arbeiten, nur ist es fuer ein Adressbuch in PHP nicht wirklich von Noetten! - jeder Profi kann Flags setzen, demnach weiss er auch wieviele Zustaende er in einem int speichern kann. Dann aber auf die Plattform achten!!! - wer Listen selber schreibt hat die Zeit sie auch zu testen oder er/sie lernt gerade wie Listen funktionieren
Auch wenn ich zugeben muss das ich aus der C-GTK+ ecke bin und Java und Qt nicht mag (persoenliche Designvorstellungen), so kann ich Java und Qt nicht ihre daseinsberechtigung habsprechen. Wir reden/schreiben hier von Desktopanwendungen, da gehe ich von 32bit (oder mehr) Maschinen aus mit min. 800-1000 MHz und min. 128-256 MB Hauptspeicher. Die Meisten werden weit hoeher angelegt sein, und da ist es dann egal ob ich fuer zwei Zustaende einen int nehme oder es in zwei boolwerten speichere.
D ist toll, keine Frage und das es einen GC hat und trotzdem den delete Operator ist spitze! Nur garantiert auch keiner das der delete Operator nicht nur ein Flag freisetzt anstatt den Speicher wirklich freizugeben. D hat aber ja auch noch so seine Maengel, das fehlen des op= Operators zum Beispiel. Die Standartbibo die zumteil sehr freizuegig mit Speicher und Rechenzeit umgeht etc. pp. All dem zum trotze ist D toll, der Versuch das "beste" und "praktischte" aus C,C++,Java und C# in einer Compilersprache unterzubringen. Und ich danke den Jungs und Maedels bei Digital Mars fuer den DMD, tolle arbeit. Nur passt D ja auch nicht ganz in eure Argumentation als "gut" rein ;)
Liest sich so als hättet ihr OOP nicht verstanden. Euren Code möchte ich gar nicht sehen, das kann ich mir richtig vorstellen wie der aussieht. Von Pattern habt ihr sicher auch noch nie was gehört oder es ist für euch das selbe Teufelswerk.
>(nicht ganz so hart gemeint aber das ( 2 + 4 ) gleich ( 2 bitor 4 ) ist sollten Coder schon wissen)
schon klar und 3|5=8?!? Wenn man auf Höhlen und Felle um die Hüften steht, kann man natürlich auf alles verzichten. Nein, Hardcorecoden ist nur in ganz speziellen Situationen das Mittel der Wahl. Man sollte lieber die Problemstellung im Auge behalten. Auf Performance und Aussehen kommt es erst in zweiter Linie an.
:-) Das ist der coolste Beitrag den ich seit vielen Monaten hier gelesen habe! Vielen Dank! Ich werde ihn mal in einen Blog mit den besten Witzen zu Programmierung stellen. Das ist die Art von Satire, mit der man sich Fans schaffen kann! Also im Ernst, wenn du noch nicht mit dem Schreiben von Satire Geld verdienst, solltest du das schnellstens machen, dein Stil ist echt klasse - die Ironie: spitze - das Geek-mäßige Gefasel von der Lehre des "echten Codes: super! :-) Programmieren kannst du dann ja in der Rente dann immer noch lernen - vielleicht findest du dann ja echt ne Firma, die mit "Bastelei" Geld verdient -das würde dem ganzen die Krone aufsetzen ;-) Hmm, echt schade, dass es in diesem Forum viele Leute gibt, die nicht mal das nicht kapieren konnten und echt glauben, du seist ein Coder - fast so wie wenn einer glaubt, dass Cobra 11 real ist *ggg*
Hat Trolltech endlich begriffen das C++ eine Sackgasse ist.
1. C++ Bibliotheken sind bis heute nicht zwischen verschiedenen Compilern kompatibel. 2. Die meisten Sicherheitsprobleme sind auf Sprachunzulänglichkeiten von C/C++ zurückzuführen. 3. C++ fehlen einheitliche Standards, jede Bibliothek bringt ihren eigenen "String" mit und macht das Kombinieren von Bibliotheken zur Qual. Es fehlen einheitliche Standards zu vielen Bereichen. Angefangen beim String, über eine standardisierte möglichkeit den Bildschirm anzusprechen bis hin zu fehlenden Datenbankschnittstelle. Über etwas abstrusere Schnittstellen wie z.B. zu Message Orientated Middleware oder einfach Soundinterface braucht man gar nicht erst zu diskutieren. Wer zwei Bibliotheken kombinieren will wird durch die Hölle gehen, dies führt zu einer miserablen Wiederverwendbarkeit. 4. Die Sprache macht einfache Dinge kompliziert. Wer ein "Hallo Welt" schreiben will muss Pointer und Pointeraritmetik verstanden haben. 5. Die Sprache C++ macht Entwickler unproduktiv. Die Sprache C++ erfordert viel zu viele Gedanken zu Problemen die nichts mit dem eigentlichen Geschäftsprozess zu tun haben. Zusätzlich provoziert C++ Fehler während andere Sprachen Fehler vermeiden helfen. 6. Die dynamischen Aspekte der Sprache sind vollkommen unzureichend, RTTI kann man für nichts wirklich gebrauchen. 7. C++ Programme verbrauchen viel zu viel Rechenzeit zum Speichermanagement. Untersuchungen haben gezeigt, dass typische C++ Programme bis zu 30% der Rechenzeit verbrauchen um Speicher bereitzustellen. In diesen Untersuchungen schnitt z.B. Java mit ca. 5% erheblich besser ab. Ein malloc() erfordert einen komplizierten Algorithmus (best match/first match...). Java gibt einfach den obersten Teil des Heaps zurück. Und auch die Freigabe ist um vieles effizienter da die meisten (über 90%) der Objekte nur sehr kurzlebig sind werden sie unter Java nicht mehr angefasst. Nur die noch referenzierten Objekte werden kopiert.
C++ hat derartig viele Nachteile, dass mann schon lange suchen muss um ein Anwendungsfeld dafür zu finden. Für Hobbyprogrammierer mag C++ noch interessant sein (als Herausforderung) aber für Profis die kostengünstig (schnell) und zuverlässig ein Problem lösen müssen ist C++ schon seit Jahren obsolet. Das hat jetzt auch Trolltech erkannt und versucht moderne Endwicklungswerkzeuge zu unterstützen.
Ich finde ja Java auch bequemer und nutze es wo ich kann um C++ nicht anzufassen aber die Argumente die du aufführst sind doch etwas lächerlich:
1. Das war vor einigen Jahren so, inzw. sind die Standardbibs von C++ und den Implementierungen von verschiedenen Compilerherstellern auf gleichem Niveau.
2. Nur wenn C-Leute in "C++" entwickeln. 3. String ist in der Standardbib enthalten. Alles andere wie Sound ist viel zu speziell. Normalerweise gibt es dafür auf jeder Platform entsprechende APIs, soll es portabel sein, wählt man eine entsprechende API aus, für den Allerweltskram wie Sound, Datenbanken,... gibt es alles in Hülle und Fülle, man muss sich halt vorher schlau machen und sorgfältig auswählen. Deshalb nimmt man i.d.R. sowas wie Qt, da ist das wichtigste drinn und alles aus einer Hand. 4. So ein Quatsch: #include using namespace std; int main() { cout << "Hello World"; return 0;} Wo taucht hier ein Pointer auf? Das trifft nur auf Leute zu wie unter Punkt 2. 5. So ein Quatsch, das trifft wieder nur auf Leute zu wie unter Punkt 2. Die meinen dann sie müssten alles aus der STL selber nachprogrammieren und die übelsten Konstrukte in ihren Code reinverwurschten. 6. http://www.devx.com/getHelpOn/Article/10202 Vielleicht wird dann klar was man damit machen kann. 7. malloc() nutzt ein echter C++ Entwickler nicht, das ist C-Gebastel. Ich verweise wieder auf Punkt 2.
Das Hauptproblem bei C++ sind die ehemaligen C-Entwickler die zu faul sind sich auf neue Konzepte einzulassen. So sieht dann auch meisten deren Code aus: 90% C, 10% C++.
zu 1. ich meinte nicht, dass der Source nicht kompatibel ist sondern die Binärbibliotheken. Wenn ich mit einem Compiler X eine Bibliothek erstelle kann ich die mit ziemlicher Sicherheit nicht mit Compiler Y dazulinken. zu 3. das ein Sound API speziell ist kann ich vielleicht noch nach nachvollziehen aber threads und Userinterfaces gehören doch eher zum Standardrepertoire. Wenn ich mir anschaue wie viele Applikationen auf relationale Datenbanken zugerifen kann ich da ach nichts spezielles dran finden. Alles "native" zu machen erzeugt fürchterliche Migrationskosten und schrenken die Installationsbasis ein. Für einen Editor oder ähnliches mag das noch gehen aber für Geschäftsanwendungen die vielleicht nur 10 mal installiert wird rechnet sich das nicht. Aber mein Hauptargument das nichts zusammen paßt wurde nicht wirklich entkräftet. Es hilft wenig sorgfältig auszuwählen wenn man keine Wahl hat, was häufig der Fall ist. nun zu 2. und 4. Dein Beispiel ist sicher ein C++ Programm und Du hast selber nicht erkannt das Du dort einen Pointer verwendet hast. Erleutere doch mal welche Klasse oder welcher Datentyp "Hello World" ist. Und dann kannst Du auch gleich erleutern warum "Hello " + "World" nicht das gewünschte ("Hello World") Ergebnis bringt. Du hast gerade meine Argumente 4. und 5. bestätigt. zu 6. das gebe ich zurück. Schau Dir mal an was man in Java mit dem Reflection API machen kann. Und dann überlege mal warum es für Java O-R-Mapper gibt wie Sand am Meer und für C++ nicht. zu 7. Dann erleutere doch mal was ein C++ new macht und schau Dir ein paar Implementierungen an. Alle Implementierungen müssen einen freien Speicherbereich finden, welchen Algorithmus sie auch immer verwenden und wie auch immer die "Beschaffungsfunktion" heißen mag.
Von Räucherstäbchen am Mo, 31. Juli 2006 um 19:21 #
[x] Du versuchst etwas über C++ zu erzählen, bringst aber nur Argumente, die C betreffen - und zwar den Anteil, für den es unter C++ bessere Konzepte gibt.
> 3. C++ fehlen einheitliche Standards, > jede Bibliothek bringt ihren > eigenen "String" mit
Das stimmt leider, insb. bei Bibliotheken, denen std::string nicht reicht.
> . Die Sprache macht einfache Dinge > kompliziert. Wer ein "Hallo Welt" > schreiben will muss Pointer und > Pointeraritmetik verstanden haben.
Ich entwickle seit einigen Jahren mit C++/Qt und habe noch _nie_ Pointerarithmetik verwendet. Und komische Dinge mit Pointern muss man bei Qt auch nicht machen.
Mit Qt und bei sinnvollem Einsatz der C++-Sprachkonstrukte lässt es sich schon recht komfortabel entwickeln. Qt API mit Ruby macht noch mehr "Spaß", aber ob das auch für größere Projekte gut funktioniert weiß ich nicht. Man darf nur nicht alle Sprachfeatures von C++ bis zum Letzten ausreizen... dann bleibt der Code auch für andere lesbar und man bleibt von Compilermacken verschont.
aus Java die Sprache und Platform, AWT,SWT,Swing kann man dann in die Tonne treten und man muss sich nicht mehr mit C++ rumplagen wenn man Qt nutzen will.
> einem heavyweight UI-Framework implementiert ist
Und ich dachte immer, Swing wäre Heavy-Weight (-:
Ich kenne kaum ein anderes Toolkit, dass die einfachsten Dinge dermaßen kompliziert macht. Ich sag nur Gridbag. Okay, ich bin wahrscheinlich verwöhnt, und Motif/MFC etc.-Veteranen werden hier laut auflachen.
Zur Geschwindigkeit: Was sind denn die Swing-spezifischen Dinge, auf die man achten muss, damits fixer wird? Einen Layoutmanager nehmen und Widgets reinhauen, wo kann man dabei groß rumschrauben?
Tja, Verwechslung ;-)
Angeblich haben sie einige Java-typischen Prüfungen mit Reflection umgangen. So ganz ungefährlich ist das natürlich nicht. Was sie sonst noch machen, müsste ich den GUI-Programmierer fragen. Der ist auf jedenfall mit Swing glücklich, ich eher nicht (QT-verwöhnt).
> Prüfungen mit Reflection umgangen. So ganz
> ungefährlich ist das natürlich nicht.
Und dann sag nochmal jemand, C++ wäre mehr "Gefrickel" als Java.
Wenn man rumfrickeln muss, damit ein _GUI_
-_Toolkit_ performant wird, läuft irgendwas falsch mit dem Toolkit.
Die Aussage ist unqualifiziert, da die Begriffe nur rein stereotypmässig verwendete sind. Somit hat sich der Autor disqualifiziert, unabhängig von dem, was aus sagen wollte.
Konkreter Einsatz der Bytecodemanipulation liegt in der AOP und ich meine auch im Umgang mit Anotations.
ich bin nich so der java enterprise entwickler und die ganzen buzzwords find ich eh doof
Serverseitig wird nur eine Bibliothek implementiert. Innerhalb dieser werden die Eigenschaften der entsprechenden Klassen spezifiziert, z.B. Entität (Representant einer Informationseinheit z.B. in einer DB, gecached, wird freigegeben falls eine Zeit nicht mehr benötigt) oder auch andere (In EJB gibt es Entity-Beans, Session-Beans (zustandslos und zustandsbehaftet). Dabei interessiert mich bei CMP (Container managed persistance) nicht mehr, wie das Objekt in der Datenbank abgelegt wird, sondern anhand vom Code werden die Tabellen ideal angelegt. Auch die Instanzierung der Objekte ist völlig sekundär, das macht der Container, der das ganze viel allgemeiner und optimierter kann als ich. Punktum: Datenbankzugriff und Caching wird von einer Applikation gemanaged, die meine Bibliothek dynamisch nachlädt, sobald ich diese ihr zum Frass vorwerfe. Diese Bibliothek wird als serverseitige Applikation verstanden. Selbstverständlich kann man dem Container auch mehrere "Applikationen" zu Ausführung übergeben. In der EJB-Welt ist auch das Clustering gratis dabei, ich muss nichts dafür tun als das System richtig zu konfigurieren (!). Dazu gehört, dass Datenbankzugriffe nicht in meiner Applikation sondern im Container konfiguriert werden. Dies bedeutet, dass ein Name festgelegt wird, unter dem die gewünschte Datenbank angesprochen wird. Welche DB dahinter liegt, ist dem System (fast) egal. Der Vorteil ist die Betriebssicherheit (Entwicklung -> Integration -> Produktion, nur durch Transfer der Applikation von einem Container in den nächsten, Die Konfiguration bleibt unverändert, da sie nicht der Applikation zugehöirg ist sondern im Container erfolgt). Desweiteren ist der integrierte Namensdienst (JNDI) sowie der standardisierte Verzeichnisdienstzugriff sehr praktisch. Hiermit können auch Verzeichnis, NIS oder LDAP-Zugriffe durch den Container gemenaged werden.
Meiner Meinung nach ist C++ in einigen Dingen Java überlegen. Die Stärke von Java liegt jedoch nicht in der Sprache sondern in dem mächtigen Technologieportfolio, das auch für mich anfangs nur aus böhmischen Dörfern bestand.
template class FooAspect:public T { void foo() { cout<<"i'm a aspect\n";T::foo(); } };
?
Das mit AOP ist nicht ganz richtig. Ich habe einmal in iX einen Artikel gelesen, wie man auch die elegant in C++ realisieren kann (mithilfe von Templates & Namespaces). Abgesehen davon gibt es AFAIK genau wie für Java speziell dafür ausgelegte Softwarepakete.
- Dynamisches Nachladen von Libraries zur Laufzeit: Dieses geht für C sehr gut. Für C++ ist dies umständlich jedoch irgendwie noch vernünftig machbar. Mit "new" geht jedoch nichts mehr, sondern man benötigt für alles eine Factory. Wenn jemand einen anderen Weg aufzeigen könnte, wäre das eine Dokumentation an geeigneter Stelle wert.
- Fehlen von Reflection: Die Ansätze, welche ich gefunden habe, sind alle relativ ungeeignet, da sie zur Compilierzeit ablaufen, d.h. die schlussendlich verwendeten Klassen müssen bekannt sein. RTTI hilft nicht weiter, da gerade auf einen bekannten Klassentyp hin untersucht werden kann. De Forderung ist jedoch, dynamisch Objekte zu erzeugen, deren Klassen mir bei der Entwicklung nicht bekannt waren sondern nachträglich dem System zugeführt wurden (binär!) durch Analyse der Klassenstruktur. ANgeblich gäbe es eine Lösung Reflexion vom Cern, leider zeigen alle Links ins leere und ich finde nichts weiteres dazu.
Vermutlich hat Objective C diese Probleme nicht, andererseits ist es auch nicht sehr viel verwendet und in dieser Nische will ich nichts programmieren. Ich habe deshalb SOPE auch nicht mehr näher untersucht, ob es den Anforderungen sonst theoretisch genügen würde.
Die Problemkonstellation macht mir einiges klar.
Oder C-1=B? Ist das überhaupt zulässig?
Zu Java:
Manches in Java ist schon deutlich eleganter als in C++. Polymorphie z.B. Die API mag ich auch, jedenfalls die grundlegenden Klassen. Swing ist allerdings großer letzte Mist. In vielen Bereichen wiederum gibts gute libs, die meistens ein halbwegs gutes Design haben und brauchbar dokumentiert sind. Javadoc als Konvention hat schon Vorteile.
Was noch stört: Dass String als Referenzen durch die Gegend geschoben werden; dass ich keine Parameter als const deklarieren kann. Die JAR-Hell, sobald die verwendeten Libs verschiedene Versionen irgendwelcher anderen libs benötigen.
Serverbasiertes würde ich jederzeit in Java schreiben, für Desktop-Anwendungen kam es bisher nicht in Frage... Mal sehen ob Jambi daran was ändert.
oder was ist da eleganter?
final?
Eine Stringvariable, die als final deklariert wurde, kann nicht wieder geändert werden. Bei einem String-Objekt gilt das sowohl für die Referenz, als auch für den Inhalt, weil ein String in Java immutable ist. Damit hat man definitiv eine Konstante.
java:
class Foo { public int a; }
final Foo f;
f.a=5; <-- ok.
f=f2; <-- nee
c++
class Foo { public: int a; };
const Foo* f1;Foo* const f2;
f1->a=5; <-- neee
f1=blubb; <-- ok.
f2->a=5; <-- ok.
f2=blubb; <-- neee
Klar in C/C++ ist das besser, mit lausigen char*... LOL
Ich meine eine vernünftige String-Klasse, wie QString. Wer will, darf natürlich auch GLib::ustring oder std::string (das aber bitte nicht für GUI-Anwendungen) benutzen.
"In a perfect world the C++ Standard Library would contain a UTF-8 string class. Unfortunately, the C++ standard doesn't mention UTF-8 at all. Note that std::wstring is not a UTF-8 string class because it contains only fixed-width characters (where width could be 32, 16, or even 8 bits)."
also richtig ist das ISO C++ nichts von unicode weiss,richtig ist aber auch das es seit C99 __STDC_ISO_10646__ gibt,was von der implementierung definiert wird um anzuzeigen das wchar_t unicode (also wohl UCS-4) ist.
also mein wstring ist ucs-4,und deiner?
ganz nebenbei ist eigentlich total egal welche kodierung wchar_t hat,es ist jedenfalls garantiert das es jedes zeichen des systems aufnehmen kann. (nein msvc ist in diesem punkt nicht konform)
Aber durchgängig 4 bytes pro zeichen ist besser? UTF8 spart hier immerhin, wenn ASCII-Zeichen verwendet werden.
Kommt natürlich immer auf die Anwendung an, aber ich brauche dann meistens doch eher nur sequentiellen zugriff auf die zeichen in einem string. und das lässt sich ja hübsch optimieren (in der String-Klasse gekapselt).
Ein Random Access Stringtype hat aber meisten bei der Textbearbeitung Vorteile gegenüber einem mehr oder weniger sequentiellen Typ. Vermutlich aus diesem oder ähnlichen Gründen sind daher auch QString und java.lang.String intern 16-Bit Unicode
also kommt man bei 16 bit bei einer multiword kodierung raus (huhu UTF-16)....naja das passiert wenn man den standard zu genau fasst (huhu java...huhu 16 bit char *g*)
aber um nicht noch mehr "komplexität" zu bekommen würd ichs begrüssen wenn sie grade den grafischen teil in swt implementieren würden. (ggf halt noch ein paar eigene klassen).
das ist meiner meinung nach die perfekte vorlage dafür, einfach die jni klassen in qt implementieren und fertig, keine(bzw kaum eine) zeile javacode nötig und die grafischen "bindings" sind fertig.
Können diese Chat ähnliche Gespräche gespeichert oder gelesen (vom Chef) werden?
Kann man das löschen?
Bitte um Antwort
Trolltech's Qt-Java bindings
Miguel de Icaza on Open Source Java
Und hier noch einer von Cies Breijs:
KDE and QtJava
Nochmals klasse.
ruediger
> Desktop anpassen
Ich warte noch auf ein HIG-Abstraction-Layer ;-)
> Ich kann mit gtkmm ein Programm schreiben, das sich wunderbar in KDE einpasst, und
> ich kann mit Qt eine Applikation schreiben, die sich an die GNOME Interface
> Guidelines hält.
Das wird bei der Verwendung von Datei- oder Druckdialogen aber schwierig, es sei denn, du willst die im anderen toolkit reimplementieren. Aber Portland soll ja hier Abhilfe schaffen.
> Ich könnte das auch mit Swing[...]
Gerade bei Swing habe ich manchmal meine Zweifel, dass man da mit vertretbarem Aufwand etwas brauchbares entwickeln kann. Manche Standardwidgets sind einfach grottig.
Warum kann man z.B. bei labels kein Wordwrap einstellen? Zu große Toolbars (ok, schlechtes Design der Anwendung) werden nicht vernünftig gehandlet, etc. pp.
> es ist abgesehen von der (unwichtigen) Optik völlig egal...
So unwichtig ist die auch nicht. Swing- oder Motif-Anwendungen verursachen Augenkrebs. Aber sie wird oft als einziges Kriterium für Integration und Konsistenz genannt, und das ist natürlich Quatsch.
Auch wenn ich jetzt einigen auf die Fuesse pette. Java und Qt sind ein irrtum! Und ich bin keine Anhaenger der C - GTK+ Fraktion!
) kamen immer wieder die gleichen Fragen auf
Java und Qt (auch wenn es sich bessert) sind einfach zu abstrakt im Design. Abstraktion ist wichtig um die lesbarkeit und wartbarkeit von Code zu verbessern, nur zu hohe Abstraktion fuehrt zu einem sich potenzierenden Leistungsverlust und zur Unlesbarkeit.
In unserer Abteilung (Forschung/Entwicklung bei XX
- warum muss ein "simpler Typ" ein Object sein? (speicher- rechenzeitverschwendung)
- warum muss man durchreichen fuer exeptions schreiben? (rechenzeitverschwendung)
- warum kann ich eine Datei nicht zeichenweise auslesen sondern erst komplett in den Seicher laden bzw. habe keine Kontrolle wie das Framework es anstellt? (kontrollverlust)
...
Qt hat bei uns den "ruf" Javadesign in C++ zu provozieren. Hart ausgedrueck, ist aber so.
Ich moechte jetzt keinen Flamewar vom Zaun brechen, nur fuehren Qt und Java zu schlechten Programmierstil. Es wird nicht mehr auf die Speicherverwaltung geachtet (in Java nicht zu umgehen aber Qt, bitte). Es wird alles moeglich in den Speichergeladen und ewig dort gehalten. Es wird mit Objecten um sich geworfen als waehre es Fallobst.
Sicherlich kann man auch in Java bzw. mit Qt "sauber" Coden wenn man es moechte. Unsere Erfahrungen gehen aber einhellig dort hin das es fuer nicht "wichtig" gehalten wird. Auf Fragen in den einschlaegigen Mailinglists bekommt man sehr haeufig die Antwort: "Der GC macht das schon!". Sowas spricht nicht fuer die Java Qt Fraktion!
Ein paar kleine Ueberzeugungen von uns:
- Code ist fuer Coder da
- wer Coden will sollte eine Vorstellung haben wie der Speicher und Rechner arbeitet (PDA, PC etc. im Schema immer gleich)
- Coder wissen was ein int ist und wie man mehrere Zustaende in einem int speichern kann
- Coder wissen wo der this-Zeiger herkommt und warum er da ist
- wer nicht rechnen kann sollte keine Programme fuer Rechner schreiben (nicht ganz so hart gemeint aber das ( 2 + 4 ) gleich ( 2 bitor 4 ) ist sollten Coder schon wissen)
- wenn ich ein Muster in einer Datenmenge suche kann dieses durch maximal zwei durchgaenge (meist schon im ersten) gefunden werden
- wenn ich ein Glied aus einer Kette zerstoeren moechte muss ich erst den "next-Zeiger/Referenz" umhaengen um nicht die Kette zu zerstoeren
- AlgoDat heisst: die Breitensuche verstanden zu haben
Klar sind Sprachen toll mit dem jeder seiner Mutter ein Adressbuch schreiben kann. Aber im Produktivbereich sollte Fachwissen nicht ein Framework mit zu strenger "Aufpassermanier" den Ton angeben.
Auch wenn sich hier einiges "getrollt" anhoert oder/und nach einem Flameaufruf, das sollte es nicht sein. Nur mal ein Statment von einer Gruppe die sich seid einigen Jahren mit den Vor- und Nachteilen bestehender "Loesungen" befasst.
otc
Peter Paul and Mary
P.S.: Seid einigen Monaten wird bei uns mit "D" von Digital Mars rumgespielt. Sieht sehr sehr gut aus, vorallem fuer sein alter.
Darf man fragen wovon du sprichst? Ist QString für dich ein simpler Typ? Wo wird Rechenzeit verschwendet?
> warum kann ich eine Datei nicht zeichenweise auslesen sondern erst komplett in den Seicher laden bzw. habe keine Kontrolle wie das Framework es anstellt? (kontrollverlust)
Muß man nicht. Im Übrigen kann man von Klassen erben und Algorithmen reimplementieren die einem nicht gefallen. Aber das hättest du auch wissen können.
> Code ist fuer Coder da
Autsch. Klingt nach Frickelfraktion.
> Auch wenn sich hier einiges "getrollt" anhoert
Oh ja.
> Nur mal ein Statment von einer Gruppe die sich seid einigen Jahren mit den Vor- und Nachteilen bestehender "Loesungen" befasst.
Den Beweis bleibst du schuldig. Viel erzählen kann jeder.
Was Du und deine Firma offensichtlich nicht verstanden haben, ist, dass Einfachheit und Abstraktion die einzigen Mittel sind, um immer komplexer werdende Applikationen zu bewältigen - man muss sich von Sachen wie Speicherverwaltung usw. freimachen, um sich um die wichtigen Dinge zu kümmern. Es heißt ja nicht umsonst, dass ein Informatiker zu quasi jedem nichttrivialen Problem erstmal eine neue Sprache entwickelt :o). Ich will jetzt nicht sagen, dass Java die Lösung aller Probleme sei (allein weil es nicht frei ist, ist es für mich keine Alternative), aber Java, C# usw. zeigen doch eindeutig, wohin der Trend geht.
> (die man wohl eh nicht in Qt schreiben würde))
Gibt es überhaupt Applikationen mit grafischer Oberfläche, die Geschwindigkeitskritisch sein müssen?
Abgesehen von reinen 3d Anwendungen fällt mir da nichts ein.
So schnell wie der Rechner rechnet, kann der Benutzer gar keine "echtzeit GUI" bedienen!
Was ich damit sagen will.
Wenn ein Arbeitsprozess etwas in Echtzeit machen soll,
dann ist die GUI von dem Echtzeitkern getrennt.
Die GUI dient lediglich zur Ansteuerung und Statusabfrage des Echtzeitprozesses/-kerns
und mir ist keine Arbeitsprozess bekannt, dessen Statusabfragen im ns Bereich
garantiert werden muß!
Denn so schnell kann, wie schon gesagt, kein Mensch sehen, erkennen und handeln.
Ich sehe daher also kein Problem, für eine Echtzeitanwendung QT als GUI zur Ansteuerung zu verwenden.
Nenne mir bitte mal einen Anwendungsfall in dem eine GUI (also so eine mit Buttons, Fenstern und Co) in quasie Echtzeit aktualisiert werden muß.
> Geschwindigkeitskritisch sein müssen?
Immer dann, wenn man in kurzer Zeit viele Daten verarbeiten muss, und der Benutzer erwartet, dass das Ergebnis möglichst schnell angezeigt wird.
In einem Mail-Client z.B., wenn man tausende Mails nach irgendwas filtern möchte.
Aber selbst da ist es kaum sinnvoll, deshalb Abstraktion und gutes Design aufzugeben, weil 95% der Anwendung nicht geschwindigkeitskritisch sein werden. An den 5% kann man noch gesondert rumschrauben. Und Qt ermöglicht genau das, Abstraktion wo möglich, low-level-Optimierung wo nötig.
> dass das Ergebnis möglichst schnell angezeigt wird.
Das ist doch Unsinn, dann muß die Anwendung lediglich möglichst schnell sein,
aber Echtzeitfähig, daß muß sie definitiv nicht sein.
Echtzeitfähig ist z.B. wenn ein Computer ein Stück Metall zwischen zwei Magenten genau
in der Mitte halten soll. Da ist Echtzeitfähigkeit im Nanosekunden bereich notwendig.
Aber definitiv nicht um so eine Liste darzustellen.
Oft ist ja die Argumentation: "Geschwindigkeit bei GUI-Anwendungen ist fast egal, so schnell kann der User ja eh nicht klicken".
Wenn aber pro Klick viele Daten angezeigt werden müssen, dann muss das List widget eben doch schnell sein.
> Fragen auf
>[simple types als Object]
>[Exceptions]
>[Datei laden]
?? die simple types sind in Java keine Objekte. es gibt auch entsprechende klassen, aber die muss man ja nicht benutzen (außer in containern).
> "Der GC macht das schon!". Sowas spricht nicht fuer die Java Qt Fraktion!
Ich weiß nicht, was das jetzt mit Qt zu tun hat. Dort werden nur child widgets gelöscht, wenn das parent widget gelöscht wird. Das wars mit GC. Bist du sicher, dass du Qt nicht mit Swing verwechselst?
> Code ist fuer Coder da
Ist das nicht eine Tautologie?
> das ( 2 + 4 ) gleich ( 2 bitor 4 ) ist sollten Coder schon wisse
Das braucht man bei Desktopanwendungen eher selten.
> - wenn ich ein Glied aus einer Kette zerstoeren moechte [...]
Ja, und? Machen die Container-Klassen von Qt das falsch?
Und wer will überhaupt selbst Listenklassen implementieren?
> Aber im Produktivbereich sollte Fachwissen nicht ein Framework mit zu
> strenger "Aufpassermanier" den Ton angeben.
Ohje, C-Hacker? Die haben auch immer Angst davor, dass ihnen jemand "die Kontrolle wegnimmt", bei Dingen, die absolut performance-unkritisch sind. Dafür bauen sie dann Buffer Overflows und wasweißich noch für Bugs ein, weil sie es mal wieder selbst schlecht lösen müssen, statt eine Bibliothek zu nehmen.
Und in 95% der Fälle ist erhöhte Abstraktion nützlich, erhöht Lesbarkeit, reduziert die Komplexität und man vermeidet Bugs. Außerdem ist man auch noch produktiver.
An den restlichen 5% will man dann natürlich rumschrauben können.
Da ist man dann bei C++ gegenüber Java im Vorteil.
Und Qt hat keine Aufpassermanier, es ist einfach eine gut designte Bibliothek. Zur Effizienz usw: Wir reden von Desktopanwendungen. Da muss man oft nur an recht wenigen Stellen optimieren. Meistens dann, wenn man irgendwo viele Daten verarbeiten und bzw. anzeigen lassen will.Und das sollte man nicht auf Verdacht tun, sondern mit Profiling-Ergebnissen. Sonst kommt nur unleserlicher, "optimierter" Code bei raus, bei dem 99% der "Optimierungen" überhaupt keinen spürbaren Effekt haben.
Man kann nur immer wieder auf den Artikel Optimization is your worst Enemy verweisen.
> Seid einigen Monaten wird bei uns mit "D" von Digital Mars rumgespielt.
Das hat doch auch GC, oder?
- vertikale Applikationen: von UI bis DB in einem Block durchprogrammiert. Keine Verallgemeinerung, keine Wiederverwendung möglich
- undurchsichtige Verwebung der Applikationen: den Umstand, dass die Applikationen keine Informationen untereinander austauschen können, wurde mit spezifisch implementierten Schnittstellen abgeholfen.
- Zahn der Zeit: Die Applikationen wurden erweitert um Funktionen, an die man bei der Implementation nicht dachte, mittlerweile gab es Stellenwechsel, da die Sprache nicht aufpasst und die neuen Mitarbeiter nicht alles Wissen, was der Vorgänger sich gedacht haben, gibt es neue, ganz perfide Fehler, nach denen wochenlang gesucht werden kann.
- Wartbarkeit -> 0: Ergibt sich aus den oben genannten Punkten.
- Fachbereichsknowhow in sterbender IT vergraben: Im Rahmen der Rationalisierung wurde das Fachwissen, welches automatisierbar ist, in IT gegossen. Damit wurden die IT-ler zu den Fachspezialisten, neue Mitarbeiter sind jedoch nicht als solche ausgebildet. Die bisherigen Technologien ermöglichten nicht, sowohl die Automatisierung als auch das verbleiben des Fachwissens im Fachbereich zu vereinen. In der Realität wusste in der Vergangenheit der Banker genau, wie die Abläufe funktionieren und er wusste was er wollte, heute kann man ihn fragen und er bleibt immer wage, da er die Abläufe selbst nicht versteht ("das müsst doch ihr wissen"). Wer hat jetzt die Bankfachausbildung genossen? . Die Programme vor 10-20 Jahren, sonst weiss niemand mehr Bescheid!
Ein Problem ist keines, wenn ein anderes um Grössenordnungen mehr schmerzt. Deshalb ist Speicherbedarf kein Problem, auch wenn es technich gesehen eines ist. Neuentwicklung verkorkster Applikationen oder Bereinigungen kosten Millionen!!! Die Löhne und Implementierungszeiten sind das Problem und alles, was den Entwicklern Arbeit abnimmt, ist willkommen (ich bin nicht für niedrigere Löhne!). Die IT-Landschaft bei den Banken ist in einem desolaten Zustand (europaweit) und ein Aufräumen mit den traditionellen Methoden ist in einer "elapsed Time" von 10 Jahren möglich, mit Sprachen penetranter Eigenschaften für Programmierer technischer Detaillösungen oder PDA-Software sind genau hier die Lösung (Beispiele für erfolgreiche, stabile und flexible Umsetzung in einem Bruchteil der Zeit, und damit Kosten, sind mir bekannt).
Schlussfolgerung:
- In vielen technischen Bereichen, insbesonderewenn garantierte Reaktionszeiten verlangt werden, hat Java nichts zu suchen. Manchmal ist sogar noch Assembler angesagt.
- In Dienstleistungsbereichen ist Java die erste Wahl.
Man kann Java sehr wohl echtzeitfähige Anwendungen schreiben nur auf denn Garbage Collector muss man dann eben verzichten. Es gibt übrigens auch Java-Assembler, aber das nur so am Rande. Assembler hat in der Anwendungsentwicklung gar nichts verloren, sondern nur in der Treiber-Entwicklung. Schön wenn man sich erst über vertikale Applikationen beschwert und wenige Sätze später nicht mal zwischen Treiber- und Anwendungsentwicklung trennen will, das gibt natürlich 1a-Reusability
In der Anwendungsentwicklung kann es notwendig sein, einen Teil hochoptimiert (bitte als Library) in Assembler zu implementieren. Ein ehemaliger Entwickler aus unserem Konzern hat jetzt gerade so ein Problem, dass er durch Verwendung der SSE2-Erweiterungen erhebliche Performancevorteile selbst gegenüber C herausholt (Verwendung des Intel-Compiler, der das auf dem Papier eigentlich ideal verwenden sollte). Ein messbarer Faktor von 4 in der Ausführungsgeschwindigkeit erlaubt an der performancerelevanten Stelle den punktuellen Einsatz von Assembler. Ob das Sprachengemisch schön ist, ist ausnahmsweise untergeordneter Priorität (es geht am Schluss schliesslich darum, ob der Cluster aus 5 oder 20 Maschinen besteht!).
Der Coder sollte aber auch wissen, dass 2 + 4 bereits vom Compiler zusammenaddiert wird.
Ansonsten gibt dein Posting nicht wirklich viel her:
- Was bezeichnest du als primitive Typen? char, int etc. sind auch in Java und C++ einfache Typen.
- Bzgl. Dateien: Kann es seien das du hier versuchst das Streaming zu kritisieren? Wenn ja, ganz schlechter Versuch!
- Qt hat keinen default GC. dazu werden unter C++ zusätzliche Bibliotheken benötigt.
- Wenn du in C++ keine Exceptions verwenden willst, lass es doch einfach!
Kann es sein, das du den Unterschied zwischen prozeduralem und objektorientiertem Denken nicht so ganz verinnerlicht hast, oder wie soll ich deine Kritik bzgl. Javadesign interpretieren?
Gerade im Produktivbereich kann ein Framework mit strenger Aufpassermanier viele Fehler vermeiden helfen. Schließlich haltet ihr euch ja auch freiwillig an best. Coding Guidelines (zumindest hoffe ich das).
Gruss
Wenn ich die Aussage(n), die US-Tastatur und die Namen zusammenziehe kann ich mir ziemlich genau vorstellen welche Gruppe hier gepostet hat
Schoen das ihr hier doch mal vorbeischaut, wenn auch auf provokante Art.
Und wenn ihr die Diskussion schon nach aussen tragt.
- Code ist fuer die da die ihn lesen koennen und/oder die lernen wollen ihn zu lesen und zu schreiben!
- jeder Profi-Hacker weiss wie Speicher und Rechner arbeiten, nur ist es fuer ein Adressbuch in PHP nicht wirklich von Noetten!
- jeder Profi kann Flags setzen, demnach weiss er auch wieviele Zustaende er in einem int speichern kann. Dann aber auf die Plattform achten!!!
- wer Listen selber schreibt hat die Zeit sie auch zu testen oder er/sie lernt gerade wie Listen funktionieren
Auch wenn ich zugeben muss das ich aus der C-GTK+ ecke bin und Java und Qt nicht mag (persoenliche Designvorstellungen), so kann ich Java und Qt nicht ihre daseinsberechtigung habsprechen. Wir reden/schreiben hier von Desktopanwendungen, da gehe ich von 32bit (oder mehr) Maschinen aus mit min. 800-1000 MHz und min. 128-256 MB Hauptspeicher. Die Meisten werden weit hoeher angelegt sein, und da ist es dann egal ob ich fuer zwei Zustaende einen int nehme oder es in zwei boolwerten speichere.
D ist toll, keine Frage und das es einen GC hat und trotzdem den delete Operator ist spitze! Nur garantiert auch keiner das der delete Operator nicht nur ein Flag freisetzt anstatt den Speicher wirklich freizugeben. D hat aber ja auch noch so seine Maengel, das fehlen des op= Operators zum Beispiel. Die Standartbibo die zumteil sehr freizuegig mit Speicher und Rechenzeit umgeht etc. pp. All dem zum trotze ist D toll, der Versuch das "beste" und "praktischte" aus C,C++,Java und C# in einer Compilersprache unterzubringen. Und ich danke den Jungs und Maedels bei Digital Mars fuer den DMD, tolle arbeit. Nur passt D ja auch nicht ganz in eure Argumentation als "gut" rein ;)
naja, bis die Tage
mah
>(nicht ganz so hart gemeint aber das ( 2 + 4 ) gleich ( 2 bitor 4 ) ist sollten Coder schon wissen)
schon klar und 3|5=8?!? Wenn man auf Höhlen und Felle um die Hüften steht, kann man natürlich auf alles verzichten. Nein, Hardcorecoden ist nur in ganz speziellen Situationen das Mittel der Wahl. Man sollte lieber die Problemstellung im Auge behalten. Auf Performance und Aussehen kommt es erst in zweiter Linie an.
>Forschung/Entwicklung bei XX
Welches Business?
-J
Das ist der coolste Beitrag den ich seit vielen Monaten hier gelesen habe! Vielen Dank!
Ich werde ihn mal in einen Blog mit den besten Witzen zu Programmierung stellen. Das ist die Art von Satire, mit der man sich Fans schaffen kann! Also im Ernst, wenn du noch nicht mit dem Schreiben von Satire Geld verdienst, solltest du das schnellstens machen, dein Stil ist echt klasse - die Ironie: spitze - das Geek-mäßige Gefasel von der Lehre des "echten Codes: super! :-)
Programmieren kannst du dann ja in der Rente dann immer noch lernen - vielleicht findest du dann ja echt ne Firma, die mit "Bastelei" Geld verdient -das würde dem ganzen die Krone aufsetzen ;-)
Hmm, echt schade, dass es in diesem Forum viele Leute gibt, die nicht mal das nicht kapieren konnten und echt glauben, du seist ein Coder - fast so wie wenn einer glaubt, dass Cobra 11 real ist *ggg*
Cheers!
1. C++ Bibliotheken sind bis heute nicht zwischen verschiedenen Compilern kompatibel.
2. Die meisten Sicherheitsprobleme sind auf Sprachunzulänglichkeiten von C/C++ zurückzuführen.
3. C++ fehlen einheitliche Standards, jede Bibliothek bringt ihren eigenen "String" mit und macht das Kombinieren von Bibliotheken zur Qual. Es fehlen einheitliche Standards zu vielen Bereichen. Angefangen beim String, über eine standardisierte möglichkeit den Bildschirm anzusprechen bis hin zu fehlenden Datenbankschnittstelle. Über etwas abstrusere Schnittstellen wie z.B. zu Message Orientated Middleware oder einfach Soundinterface braucht man gar nicht erst zu diskutieren. Wer zwei Bibliotheken kombinieren will wird durch die Hölle gehen, dies führt zu einer miserablen Wiederverwendbarkeit.
4. Die Sprache macht einfache Dinge kompliziert. Wer ein "Hallo Welt" schreiben will muss Pointer und Pointeraritmetik verstanden haben.
5. Die Sprache C++ macht Entwickler unproduktiv. Die Sprache C++ erfordert viel zu viele Gedanken zu Problemen die nichts mit dem eigentlichen Geschäftsprozess zu tun haben. Zusätzlich provoziert C++ Fehler während andere Sprachen Fehler vermeiden helfen.
6. Die dynamischen Aspekte der Sprache sind vollkommen unzureichend, RTTI kann man für nichts wirklich gebrauchen.
7. C++ Programme verbrauchen viel zu viel Rechenzeit zum Speichermanagement. Untersuchungen haben gezeigt, dass typische C++ Programme bis zu 30% der Rechenzeit verbrauchen um Speicher bereitzustellen. In diesen Untersuchungen schnitt z.B. Java mit ca. 5% erheblich besser ab. Ein malloc() erfordert einen komplizierten Algorithmus (best match/first match...). Java gibt einfach den obersten Teil des Heaps zurück. Und auch die Freigabe ist um vieles effizienter da die meisten (über 90%) der Objekte nur sehr kurzlebig sind werden sie unter Java nicht mehr angefasst. Nur die noch referenzierten Objekte werden kopiert.
C++ hat derartig viele Nachteile, dass mann schon lange suchen muss um ein Anwendungsfeld dafür zu finden. Für Hobbyprogrammierer mag C++ noch interessant sein (als Herausforderung) aber für Profis die kostengünstig (schnell) und zuverlässig ein Problem lösen müssen ist C++ schon seit Jahren obsolet. Das hat jetzt auch Trolltech erkannt und versucht moderne Endwicklungswerkzeuge zu unterstützen.
1. Das war vor einigen Jahren so, inzw. sind die Standardbibs von C++ und den Implementierungen von verschiedenen Compilerherstellern
auf gleichem Niveau.
2. Nur wenn C-Leute in "C++" entwickeln.
3. String ist in der Standardbib enthalten. Alles andere wie Sound ist viel zu speziell. Normalerweise gibt es dafür auf jeder Platform entsprechende APIs, soll es portabel sein, wählt man eine entsprechende API aus, für den Allerweltskram wie Sound, Datenbanken,... gibt es alles in Hülle und Fülle, man muss sich halt vorher schlau machen und sorgfältig auswählen. Deshalb nimmt man i.d.R. sowas wie Qt, da ist das wichtigste drinn und alles aus einer Hand.
4. So ein Quatsch:
#include using namespace std;
int main() { cout << "Hello World"; return 0;}
Wo taucht hier ein Pointer auf? Das trifft nur auf Leute zu wie unter Punkt 2.
5. So ein Quatsch, das trifft wieder nur auf Leute zu wie unter Punkt 2. Die meinen dann sie müssten alles aus der STL selber nachprogrammieren und die übelsten Konstrukte in ihren Code reinverwurschten.
6. http://www.devx.com/getHelpOn/Article/10202
Vielleicht wird dann klar was man damit machen kann.
7. malloc() nutzt ein echter C++ Entwickler nicht, das
ist C-Gebastel. Ich verweise wieder auf Punkt 2.
Das Hauptproblem bei C++ sind die ehemaligen C-Entwickler die zu faul sind sich auf neue Konzepte einzulassen. So sieht dann auch meisten deren Code aus: 90% C, 10% C++.
zu 3. das ein Sound API speziell ist kann ich vielleicht noch nach nachvollziehen aber threads und Userinterfaces gehören doch eher zum Standardrepertoire. Wenn ich mir anschaue wie viele Applikationen auf relationale Datenbanken zugerifen kann ich da ach nichts spezielles dran finden. Alles "native" zu machen erzeugt fürchterliche Migrationskosten und schrenken die Installationsbasis ein. Für einen Editor oder ähnliches mag das noch gehen aber für Geschäftsanwendungen die vielleicht nur 10 mal installiert wird rechnet sich das nicht. Aber mein Hauptargument das nichts zusammen paßt wurde nicht wirklich entkräftet. Es hilft wenig sorgfältig auszuwählen wenn man keine Wahl hat, was häufig der Fall ist.
nun zu 2. und 4. Dein Beispiel ist sicher ein C++ Programm und Du hast selber nicht erkannt das Du dort einen Pointer verwendet hast. Erleutere doch mal welche Klasse oder welcher Datentyp "Hello World" ist. Und dann kannst Du auch gleich erleutern warum "Hello " + "World" nicht das gewünschte ("Hello World") Ergebnis bringt. Du hast gerade meine Argumente 4. und 5. bestätigt.
zu 6. das gebe ich zurück. Schau Dir mal an was man in Java mit dem Reflection API machen kann. Und dann überlege mal warum es für Java O-R-Mapper gibt wie Sand am Meer und für C++ nicht.
zu 7. Dann erleutere doch mal was ein C++ new macht und schau Dir ein paar Implementierungen an. Alle Implementierungen müssen einen freien Speicherbereich finden, welchen Algorithmus sie auch immer verwenden und wie auch immer die "Beschaffungsfunktion" heißen mag.
> jede Bibliothek bringt ihren
> eigenen "String" mit
Das stimmt leider, insb. bei Bibliotheken, denen std::string nicht reicht.
> . Die Sprache macht einfache Dinge
> kompliziert. Wer ein "Hallo Welt"
> schreiben will muss Pointer und
> Pointeraritmetik verstanden haben.
Ich entwickle seit einigen Jahren mit C++/Qt und habe noch _nie_ Pointerarithmetik verwendet. Und komische Dinge mit Pointern muss man bei Qt auch nicht machen.
Mit Qt und bei sinnvollem Einsatz der C++-Sprachkonstrukte lässt es sich schon recht komfortabel entwickeln. Qt API mit Ruby macht noch mehr "Spaß", aber ob das auch für größere Projekte gut funktioniert weiß ich nicht.
Man darf nur nicht alle Sprachfeatures von C++ bis zum Letzten ausreizen... dann bleibt der Code auch für andere lesbar und man bleibt von Compilermacken verschont.