C++ ist kein Rapid Development im Gegensatz zu Python
Hm, ich würde mich freuen, wenn man in Tabellen nicht nur nach einem key, sondern nach mehreren sortieren könnte - die GUI bietet das leider nicht an. Wenn man große Tabellen in Anwendungen hat, ist der Hauptkey nur die grobe Sortierung und die Verfeinerung kann man nicht per GUI steuern
Nur leider schafft eben kaum jemand das Skalpell richtig zu führen, sonst hätte man nicht in fast jedem großem Programm, was mit C++ oder C geschrieben ist Speicherlecks.
Andersherum ist es aber auch nicht besser: Es gibt viele Programme (vor allem Spiele und Animationen), die dadurch lahmen, dass der Garbage Collector an unpassenden Stellen arbeitet, was einiges an Performance klaut.
Ein GC ist heutzutage in der Regel schneller als manuelle Speicherverwaltung, wenn genügend Speicher vorhanden ist. Die Zeiten dummer Mark-&-Sweep-Collectoren sind schon lange vorbei...
Das sollte man annehmen, allerdings gab es das Problem immerhin noch auf Dalvik. Keine Ahnung, wie der GC dort funktioniert, allerdings gab es einen Blogartikel darüber, wie man versuchen konnte, das Problem zu umgehen. In der neuen Version wahrscheinlich nicht mehr problematisch, aber die älteren Dalvik-Versionen sind ja jetzt auch nicht uralt.
Ja, es ist schlimm in C++ zu programmieren. Im Gegensatz zu Python oder Java muss man a) die Bibliotheken mit deinem Computer übersetzen, sonst kannst du sie nicht benutzen, b) es dauert eine Ewigkeit kleine Änderungen zu übersetzen (und eben auch zu testen), dann c) die Syntax von C++ ist einfach grauenhaft. Das fängt schon damit an, dass es Header und Code Dateien gibt, dass man ohne den Precompiler und Macros nicht auskommt, oder kleine Dinge, wie dass man eine Funktion zuerst deklarieren muss um sie zu benutzen oder das man private Felder und Methoden öffentlich bekannt machen muss (man muss sie in der Header Datei mitangeben, selbst bei C muss man das nicht).
C++ ist kein Skalpell, sondern ein Multizweck-Werkzeug aus den 80er. Ich nehme doch lieber Sprachen, die etwas mehr spezialisierter sind, aber dafür ich schneller und sicherer an mein Ziel gelange.
Nach meinem Wissen sind die anderen "modernen" Sprachen nichts weiter als zumeist Textdateien, die von einem C/C++ Programm interpretiert werden.
Ich sehe auch nicht, wo ich mir mit solchen Sprachen Tipparbeit sparen könnte. Es sei denn in Perl mit "write only" Programmen, die man später nicht mehr lesen/verstehen kann.
Nach meinem Wissen sind die anderen "modernen" Sprachen nichts weiter als zumeist Textdateien, die von einem C/C++ Programm interpretiert werden. Dummes Gewäsch. Es gibt Dutzende Sprachen, die genau wie C oder C++ kompiliert werden, oft von einem Compiler, der in der Sprache selbst geschrieben ist (z. B. GHC für Haskell, ocamlopt für O'Caml, MLton für Standard ML usw.)
Und wenn Du nicht siehst, wie man in modernen Sprache Tipparbeit spart, dann ist Dir echt nicht mehr zu helfen. Mal zum Vergleich: Erstellen einer globalen, konstanten Liste, ohne dass es die Möglichkeit gäbe, auf eine nicht initialisierte Liste zuzugreifen.
Da sind Fehler in dem Code, da Pro-Linux blöderweise alles verschluckt, was in spitzen Klammern steht. Das neue Layout ist also nicht nur grottenhässlich, das ganze Teil ist auch noch verbuggt.
pimpl ist so ziemlich das dümmste Idiom in der C++-Welt. Abgesehen davon, dass die Unterstützung für so etwas eigentlich in die Sprache selbst gehört, setzt man die Trennung von Interface und Implementierung besser um mit einer abstrakten Basisklasse, die das Interface spezifiziert und einer davon abgeleiteten Klasse, die dieses Interface implementiert. Über statische factory-Methoden kann man dann Instanzen der Klasse erzeugen.
Im Gegensatz zu Python oder Java muss man a) die Bibliotheken mit deinem Computer übersetzen, sonst kannst du sie nicht benutzen
Auch Java Dateien müssen zuerst vom javac in Class Dateien übersetzt werden. Zumindest war das noch so als ich das letzte Mal Java benutzt hatte.
der das man private Felder und Methoden öffentlich bekannt machen muss (man muss sie in der Header Datei mitangeben, selbst bei C muss man das nicht)
Du kannst genau so wie in C mit privaten Daten verfahren, ich wüsste nicht, welcher entsprechende Teil von C von einem C++Compiler nicht verstanden werden würde.
Dann versuch doch mal ein Programm ohne den Precompiler zu schreiben. Mal ein Tipp: #include ist eine Precompiler Direktive und ohne ein #ifndef HEADERNAME_H_ #define HEADERNAME_H_ #endif kommst du in einem C++ Programm auch nicht aus.
Du kannst genau so wie in C mit privaten Daten verfahren, ich wüsste nicht, welcher entsprechende Teil von C von einem C++Compiler nicht verstanden werden würde.
Musst du natürlich nicht (pimpl) aber du kannst.
Ich kann auch in C++ wie in C programmieren. Aber dann nehme ich doch gleich C.
Auch Java Dateien müssen zuerst vom javac in Class Dateien übersetzt werden. Zumindest war das noch so als ich das letzte Mal Java benutzt hatte.
Aber der Java Compiler ist im Vergleich zu dem C++ Compiler astronomisch schnell. Dazu habe ich noch in Eclipse einen inkrementiellen Compiler, der nur das Übersetzt, was verändert wurde. Dadurch sinkt die Übersetzungszeit auf Millisekunden und das erhöht nicht nur meine Produktivität, sondern ich kann auch schnell Änderungen testen, was zu besseren Algorithmen führt. Überhaupt wird deine gesamte Arbeitsweise gleich viel dynamischer.
Öm..öh... also die Syntax von C++ enspricht ziemlich genau der von Java. Bis auf die Sache mit den Headern.
Nein, die Syntax von C++ ist ziemlich kaputt. Z.B. die Template Syntax. Man kann hier nicht einfach >> schreiben, sondern braucht ein Leerzeichen.
template <class Foo<Bar > >
Oder dieses Codestück
AA BB(CC);
Was macht dieses Codestück? Ist es eine Funktion oder definiere ich ein Objekt? Alle Sprachen können diese Frage beantworten, ohne den Kontext zu kennen (sie sind Kontext-Frei http://en.wikipedia.org/wiki/Context-free_grammar), bis auf C++. Oder auch dieses Codestück ist lustig.
> Aber der Java Compiler ist im Vergleich zu dem C++ Compiler astronomisch > schnell. Dazu habe ich noch in Eclipse einen inkrementiellen Compiler, > der nur das Übersetzt, was verändert wurde.
Du kennst make ?
Wenn Du das neumodische Zeug lieber magst, dann probier mal Qt Creator mit Qt
PS: C/C++ sind einfach Standards, die es schon lange gibt und auch noch lange geben wird.
Du meinst Makro Pre*prozessor*. Ein Precompiler ist was anderes.
Ein Precompiler übersetzt .h in ein Zwischenformat. Das spart Zeit beim Compilieren weil die Header dann nich nochmal komplett neu eingelesen werden müssen.
Zweitens: Den Space zwischen >> braucht man schon lange nicht mehr. Natürlich braucht man den. Bei einer Deklaration wie std::list l; meint g++: error: ‘>>’ should be ‘> >’ within a nested template argument list Und das ist nach dem Standard auch richtig so.
Ich kann auch in C++ wie in C programmieren. Aber dann nehme ich doch gleich C.
Wenn du willst. Gibt genug Leute die C++ vorziehen. Und das war ja auch nur eine der Möglichkeiten, die du hier einfach zusammen geworfen hast. Information Hiding ist eine Standardvorgehensweise bei objektorientierten Sprachen, so eben auch in C++, es ist ja nicht nur "C mit Klassen". Nur weil man es nicht machen muss, heißt das nicht, dass es nicht geht und auch nicht, dass es nicht normalerweise gemacht wird.
Aber der Java Compiler ist im Vergleich zu dem C++ Compiler astronomisch schnell.
Das ändert nichts an der Tatsache, dass dieser Teil deines anderen Beitrags falsch war. Der Standard Classloader von Java benötigt übersetzte Klassen.
Gut, Präcompiler mit dem Präprozessor verwechselt, Asche auf mein Haupt. Macht die Sprache auch nicht besser. Das die C++ Syntax hoch kompliziert ist und der Compiler arschlahm ändert daran auch nichts.
Was ich allerdings gefunden habe, ist auch Interessant und erklärt die Beliebtheit von Java. http://www.it-career-coach.net/2007/07/25/learning-c-programming-language-is-bad-for-your-career-c-programmers-cant-find-jobs/
Employers really want their software developers to code or write programs faster. And C/C++ fares badly at this, because it’s one of the meanest, hardest, most complex programming languages to either learn or develop real-world business applications with.
The problems of C/C++ does not stop with the difficulty of learning the language. It’s also harder, tougher and slower to develop web or business applications in.
This is the real reason why most employers will not hire C/C++ programmers for business or web application development.
Über sowas kann ich nur lachen. Mit der realität hats nämlich nix zu tun.
Zufälligerweise kam ich grad diese Woche auf die Jobs Seite von Facebook (nicht das ich da Fan von bin; Ganz im Gegenteil; Diaspora is the way to go).
Ich dachte gerade die machen viel Java. Nope!!! C++ all over the place. Ja, richtig gelesen, die suchen C++ Leute. Neben anderen Sachen natürlich und oft stehen Java und C++ nebeneinander.
Wie ich schon sagte: Das richtige Tool für den Job.
Es gibt auch noch andere Sprachen die nicht kontextfrei sind. Natürlich ist C++ hier komplizierter als zB Java und daher dauert auch die semantische Analyse länger. Dafür bietet C++ auch Features die andere Sprachen eben nicht haben.
Und wenn man diese Features zu nutzen weiss (und auch in der richtigen Dosierung; wie bei Qt zB) dann ist C++ einfach nur klasse.
Es kommt halt auf den Task an. Für etwas wo Perl das perfekte Werkzeug ist nehm ich nicht C++.
Plus mach mal eine Nested-Class in C++, welche auf Variablen des umliegenden Scopes zugreift. Richtig, geht nicht. Ok, wird gehn mit Closures in C++0x (wohl 210x). Aber das implementieren so wenige Compiler das man's einfach noch nicht verwenden kann wenn man sich nicht total an einen Compiler binden will.
Wenn es nicht gerade auf die Performance ankommt hat man mit PyQt einige Vorteile... Bis man in C++ seine Headerdateien fertig hat, hat man in Python schon das Programm fertig
Ich freue mich schon auf die Final, dann wird es hoffentlich auch wieder Binarys für Linux geben und man muss sie sich nicht selber kompilieren - für alle anderen Systeme gibts ja fertige Pakete. Ich benutze gerne Qt, aber dass sie die Linux-Programmierer so stiefmütterlich behandeln finde ich echt fürn A***
Das ist Aufgabe der Distriibution und zugehörigen Unstable-Repos und nicht des Upstream-Projekts
> Linux-Programmierer so stiefmütterlich behandeln > finde ich echt fürn A***
Was für eine dumme Aussage
Für die anderen OS gibt es die Binarys nicht weil sie bevorzugt werden sondern weil du unter Windows ein Hochschulstudium brauchst um das Zeug durch den Compiler zu bekommen.
Nein, es gibt im Gegenteil keine Binaries für Linux, weil es nur unter größten Schmerzen möglich ist, Binaries für Linux bereitzustellen. Das tun sich nur die wenigsten Upstreams an.
Das Problem ist Linux-spezifisch, nicht Projekt-spezifisch (und wenn du schon dabei bist - bei C++ Projekten ist das Problem wegen fehlender ABI-Spezifikation tendentiell schwieriger als bei C Projekten).
> Für die anderen OS gibt es die Binarys nicht weil sie bevorzugt werden sondern > weil du unter Windows ein Hochschulstudium brauchst um das Zeug durch den > Compiler zu bekommen.
Der Installer der Open Source Version von Qt unter Windows zieht Dir sogar den MinGW mit einem Click mit rein, konfiguriert und übersetzt alles. Dafür brauchst Du nun wirklich kein Hochschulstudium. Wenn Du Qt Creator verwendetst brauchst Du nicht mal $QTDIR, $QMAKESPEC und $MINGWDIR setzen.
Das ist nun schon alles recht DAU tauglich.
Das Übersetzen dauert halt etwas.
Bei Linux finde ich es ganz gut, dass man selber aus den Nokia/Trolltech Archiven übersetzt, weil man Qt dann auch in einem separaten Trolltech Verzeichnis drin hat und es keine Konflikte mit der standardmäßig installierten Qt Version gibt.
PS: Ja das Verzeichnis heißt wirklich noch Trolltech und das wird hoffentlich auch so bleiben.
> Für die anderen OS gibt es die Binarys nicht weil sie bevorzugt werden sondern weil du unter Windows ein Hochschulstudium brauchst um das Zeug durch den Compiler zu bekommen Wenn Sie meine Aussage schon als dumm hinstellen, dann sollten Sie nicht den Mund so voll nehmen und über Dinge reden, über denen Sie keinen Schimmer haben. Es ist nämlich absoluter Blödsinn, dass sich der Source von Qt für Windows schwieriger kompilieren lässt.
Und um noch mal auf meine ursprüngliche Aussage zu kommen: Aus meiner Sicht ist es extrem unschön, dass SDKs für Linux nur für Finalversionen angeboten werden, weil das Kompilieren (bei mir) Stunden dauert, während das Runterladen und Installieren eines SDKs für Linux nur Minuten dauert. Mich hält das jedenfalls davon ab neuere Versionen wie den jetzt erschienenen RC zu testen.
Als Mann des Ausgleichs würde ich gerne wissen, wie sehen denn die Fortschritte von GTK aus? Im Hinblick auf GNOME 3 tut sich da doch auch was oder?
Alle mit deprecated gekennzeichneten Funktionen werden entfernt. Außerdem gibt es folgende neuen Features:
Bei Gnome 3 werden dann alle Applikationen entfernt, die noch Funktionen verwenden, die als deprecated gekennzeichnet sind. Außerdem werden die oben aufgelisteten neuen gtk-Features verwendet.
Sie haben weiter zurückgerudert. GNOME 3 wird wohl beides beinhalten: GNOME 2 mit GTK 2 und GNOME 3 mit GTK3. Wenn die Hardware es unterstützt wird GNOME 3 verwendet ansonsten gibt es GNOME 2 als Fallback. So macht es jedenfalls Fedora (Quelle: http://fedoraproject.org/wiki/Features/Gnome3). Ubuntu wird nur GNOME 2 und nicht GNOME 3 ausliefern um diese Inkonsistenz zu vermeiden. Ist mir nicht bekannt wie Suse und debian das Problem lösen wollen aber sie werden sich wohl für den Fedora oder den Ubuntu Weg entscheiden müssen.
Also ist GNOME 3 keine Weiterentwicklung sondern ein Fork von GNOME? Ich dachte die hätten nicht soviele Entwickler, dass Sie sich das leisten können....
Deine Quelle gibt den Stand der Aufnahme von GNOME 3 in die Fedora Repos wieder. Ich kann da nicht rauslesen, dass Fedora GNOME 2 als Fallback mitliefern will - es wird lediglich nicht die GNOME Shell verwendet, sondern das "klassische" Interface (das es ebenfalls in Version 3 gibt). Mit GNOME 2 hat das erstmal nix zu tun. Schon gar nicht kann man aus der Quelle rauslesen, was Upstream GNOME macht.
Ubuntu wird nur GNOME 2 und nicht GNOME 3 ausliefern um diese Inkonsistenz zu vermeiden.
Nein, bei GNOME gibt es keine Inkonsistenz. Das Problem von Ubuntu ist anderer Natur. Sie haben nicht genug Platz, um GTK+ 2 und GTK+ 3 parallel auf ihre Installations-CD zu packen. Da einige wichtige Nicht-GNOME Programme noch GTK+ 2 verwenden (z.B. Firefox und Openoffice), haben sie jetzt ein Problem. Welche Lösung es dafür geben wird (GNOME 2 weiterverwenden, Firefox/Openoffice bei der Portierung helfen, GNOME Entwickler überzeugen, ihre neuen Programm-Versionen compile-zeit-optional auch mit GTK+ 2 laufen zu lassen, ...) wird sich erst noch zeigen.
Mit
http://doc.qt.nokia.com/4.7-snapshot/qdeclarativeview.html
hat man ein neues Widget in Qt.
Damit sollen Nichtprogrammierer oder Leute, die nur "Web Programmierung" können an Qt basierten Anwendungen mitarbeiten können.
Ähnlich ist das mit den Sprachenanbindungen für Qt, wie z.B.
http://wiki.python.de/PyQt
Ist es denn wirklich sooooo schlimm in C++ zu programmieren ?
Sollte man nicht lieber die Menschen qualifizieren ?
C++ ist kein Rapid Development im Gegensatz zu Python
Hm, ich würde mich freuen, wenn man in Tabellen nicht nur nach einem key, sondern nach mehreren sortieren könnte - die GUI bietet das leider nicht an. Wenn man große Tabellen in Anwendungen hat, ist der Hauptkey nur die grobe Sortierung und die Verfeinerung kann man nicht per GUI steuern
> Ist es denn wirklich sooooo schlimm in C++ zu
> programmieren ?
"C++ is like a sharp scalpel. Yes you can hurt yourself if you're
unskilled, inexperienced or sloppy.
Java and C# are like those scissors with rounded ends for
kids. Totally inefficent but safe for beginners."
:-)
Der Omega13
Nur leider schafft eben kaum jemand das Skalpell richtig zu führen, sonst hätte man nicht in fast jedem großem Programm, was mit C++ oder C geschrieben ist Speicherlecks.
Andersherum ist es aber auch nicht besser: Es gibt viele Programme (vor allem Spiele und Animationen), die dadurch lahmen, dass der Garbage Collector an unpassenden Stellen arbeitet, was einiges an Performance klaut.
Ein GC ist heutzutage in der Regel schneller als manuelle Speicherverwaltung, wenn genügend Speicher vorhanden ist. Die Zeiten dummer Mark-&-Sweep-Collectoren sind schon lange vorbei...
Das sollte man annehmen, allerdings gab es das Problem immerhin noch auf Dalvik. Keine Ahnung, wie der GC dort funktioniert, allerdings gab es einen Blogartikel darüber, wie man versuchen konnte, das Problem zu umgehen. In der neuen Version wahrscheinlich nicht mehr problematisch, aber die älteren Dalvik-Versionen sind ja jetzt auch nicht uralt.
Ja, es ist schlimm in C++ zu programmieren. Im Gegensatz zu Python oder Java muss man a) die Bibliotheken mit deinem Computer übersetzen, sonst kannst du sie nicht benutzen, b) es dauert eine Ewigkeit kleine Änderungen zu übersetzen (und eben auch zu testen), dann c) die Syntax von C++ ist einfach grauenhaft. Das fängt schon damit an, dass es Header und Code Dateien gibt, dass man ohne den Precompiler und Macros nicht auskommt, oder kleine Dinge, wie dass man eine Funktion zuerst deklarieren muss um sie zu benutzen oder das man private Felder und Methoden öffentlich bekannt machen muss (man muss sie in der Header Datei mitangeben, selbst bei C muss man das nicht).
C++ ist kein Skalpell, sondern ein Multizweck-Werkzeug aus den 80er. Ich nehme doch lieber Sprachen, die etwas mehr spezialisierter sind, aber dafür ich schneller und sicherer an mein Ziel gelange.
Nach meinem Wissen sind die anderen "modernen" Sprachen nichts weiter als zumeist Textdateien, die von einem C/C++ Programm interpretiert werden.
Ich sehe auch nicht, wo ich mir mit solchen Sprachen Tipparbeit sparen könnte.
Es sei denn in Perl mit "write only" Programmen, die man später nicht mehr lesen/verstehen kann.
Zitat: "Ich sehe auch nicht, wo ich mir mit solchen Sprachen Tipparbeit sparen könnte."
Na bei Python fängt es ja schon mit dem Syntax an keine ; keine {} usw usf und geht weiter mit keine Deklarationen, keine Makros usw usf.
Nach meinem Wissen sind die anderen "modernen" Sprachen nichts weiter als zumeist Textdateien, die von einem C/C++ Programm interpretiert werden.
Dummes Gewäsch. Es gibt Dutzende Sprachen, die genau wie C oder C++ kompiliert werden, oft von einem Compiler, der in der Sprache selbst geschrieben ist (z. B. GHC für Haskell, ocamlopt für O'Caml, MLton für Standard ML usw.)
Und wenn Du nicht siehst, wie man in modernen Sprache Tipparbeit spart, dann ist Dir echt nicht mehr zu helfen. Mal zum Vergleich: Erstellen einer globalen, konstanten Liste, ohne dass es die Möglichkeit gäbe, auf eine nicht initialisierte Liste zuzugreifen.
C++:
#include
class singleton {
static bool is_initialized = false;
static std::list instance;
public:
static const std::list &get_instance() {
if (!is_initialized) {
instance.push_back(1);
instance.push_back(2);
instance.push_back(3);
}
return instance;
}
};
Zugriff dann per "singleton::get_instance()";
Und jetzt in Haskell:
singleton = [1,2,3]
Zugriff einfach durch "singleton".
Da sind Fehler in dem Code, da Pro-Linux blöderweise alles verschluckt, was in spitzen Klammern steht. Das neue Layout ist also nicht nur grottenhässlich, das ganze Teil ist auch noch verbuggt.
Netter Versuch, die Lösung in C/C++ ist einfach:
const int a[3] = {1, 2, 3};
Oder wenn man unbedingt das Objekt braucht, in c++0x:
const std::list a = {1, 2, 3};
Singletons benutzen ist nebenbei sowieso schlechter Stil, und wenns wirklich sein muss kann man deinen C++-Code noch mal deutlich abspecken.
> oder das man private Felder und Methoden öffentlich bekannt machen
Musst du natürlich nicht (pimpl) aber du kannst.
pimpl ist so ziemlich das dümmste Idiom in der C++-Welt. Abgesehen davon, dass die Unterstützung für so etwas eigentlich in die Sprache selbst gehört, setzt man die Trennung von Interface und Implementierung besser um mit einer abstrakten Basisklasse, die das Interface spezifiziert und einer davon abgeleiteten Klasse, die dieses Interface implementiert. Über statische factory-Methoden kann man dann Instanzen der Klasse erzeugen.
Auch Java Dateien müssen zuerst vom javac in Class Dateien übersetzt werden. Zumindest war das noch so als ich das letzte Mal Java benutzt hatte.
Du kannst genau so wie in C mit privaten Daten verfahren, ich wüsste nicht, welcher entsprechende Teil von C von einem C++Compiler nicht verstanden werden würde.
Python wird auch kompiliert nur merkt man das nicht weil es on-the-fly geschieht.
Öm..öh... also die Syntax von C++ enspricht
ziemlich genau der von Java. Bis auf
die Sache mit den Headern.
Und ein Precompiler ist optional. Den
gibt übrigens für C auch. Hat gar nix
mit C++ zu tun. Auf Macros kann man
in C++ komplett verzichten.
Es gibt berechtigte Kritikpunkte an C++.
Aber davon hast du keinen genannt,
von der Header Geschichte mal abgesehen.
Der Omega13.
Dann versuch doch mal ein Programm ohne den Precompiler zu schreiben. Mal ein Tipp: #include ist eine Precompiler Direktive und ohne ein #ifndef HEADERNAME_H_ #define HEADERNAME_H_ #endif kommst du in einem C++ Programm auch nicht aus.
Ich kann auch in C++ wie in C programmieren. Aber dann nehme ich doch gleich C.
Aber der Java Compiler ist im Vergleich zu dem C++ Compiler astronomisch schnell. Dazu habe ich noch in Eclipse einen inkrementiellen Compiler, der nur das Übersetzt, was verändert wurde. Dadurch sinkt die Übersetzungszeit auf Millisekunden und das erhöht nicht nur meine Produktivität, sondern ich kann auch schnell Änderungen testen, was zu besseren Algorithmen führt. Überhaupt wird deine gesamte Arbeitsweise gleich viel dynamischer.
Nein, die Syntax von C++ ist ziemlich kaputt. Z.B. die Template Syntax.
Man kann hier nicht einfach >> schreiben, sondern braucht ein Leerzeichen.
Oder dieses Codestück
Was macht dieses Codestück? Ist es eine Funktion oder definiere ich ein Objekt? Alle Sprachen können diese Frage beantworten, ohne den Kontext zu kennen (sie sind Kontext-Frei http://en.wikipedia.org/wiki/Context-free_grammar), bis auf C++.Oder auch dieses Codestück ist lustig.
> Aber der Java Compiler ist im Vergleich zu dem C++ Compiler astronomisch
> schnell. Dazu habe ich noch in Eclipse einen inkrementiellen Compiler,
> der nur das Übersetzt, was verändert wurde.
Du kennst make ?
Wenn Du das neumodische Zeug lieber magst,
dann probier mal Qt Creator mit Qt
PS:
C/C++ sind einfach Standards, die es schon lange gibt und auch noch lange geben wird.
Du meinst Makro Pre*prozessor*. Ein Precompiler ist was anderes.
Ein Precompiler übersetzt .h in ein Zwischenformat. Das
spart Zeit beim Compilieren weil die Header dann
nich nochmal komplett neu eingelesen werden müssen.
Der Omega13.
Erstens: Templates gibts bei Java gar nicht. Zumindest nicht
in dieser Form. Generics bei Java sind ganz anders.
Zweitens: Den Space zwischen >> braucht man
schon lange nicht mehr.
Der Omega13.
Zweitens: Den Space zwischen >> braucht man
schon lange nicht mehr.
Natürlich braucht man den. Bei einer Deklaration wie
std::list l;
meint g++:
error: ‘>>’ should be ‘> >’ within a nested template argument list
Und das ist nach dem Standard auch richtig so.
Wenn du willst. Gibt genug Leute die C++ vorziehen.
Und das war ja auch nur eine der Möglichkeiten, die du hier einfach zusammen geworfen hast.
Information Hiding ist eine Standardvorgehensweise bei objektorientierten Sprachen, so eben auch in C++, es ist ja nicht nur "C mit Klassen".
Nur weil man es nicht machen muss, heißt das nicht, dass es nicht geht und auch nicht, dass es nicht normalerweise gemacht wird.
Das ändert nichts an der Tatsache, dass dieser Teil deines anderen Beitrags falsch war. Der Standard Classloader von Java benötigt übersetzte Klassen.
> Der Standard Classloader von Java benötigt übersetzte
> Klassen.
Ausserdem werden Äpfel mit Melonen verglichen.
Ein javac ist natürlich schnell weil er nur unoptimierten
"simplen" Bytecode erzeugt.
Beim C++ kommt noch das Linken hinzu. Das
passier halt bei Java beim starten des Programms.
Nachdem es sehr lange gedauert hat die JVM
hochzufahren.
Der Omega13
300ms sind keine "sehr lange Zeit"
Gut, Präcompiler mit dem Präprozessor verwechselt, Asche auf mein Haupt. Macht die Sprache auch nicht besser. Das die C++ Syntax hoch kompliziert ist und der Compiler arschlahm ändert daran auch nichts.
Was ich allerdings gefunden habe, ist auch Interessant und erklärt die Beliebtheit von Java.
http://www.it-career-coach.net/2007/07/25/learning-c-programming-language-is-bad-for-your-career-c-programmers-cant-find-jobs/
Du denkst also Betriebssysteme, Browser, Office-Anwendungen, Java selbst, usw. in HTML zu programmieren würde mehr Sinn machen?
Über sowas kann ich nur lachen. Mit der
realität hats nämlich nix zu tun.
Zufälligerweise kam ich grad diese Woche auf die
Jobs Seite von Facebook (nicht das ich da Fan
von bin; Ganz im Gegenteil; Diaspora is the way
to go).
Ich dachte gerade die machen viel Java. Nope!!!
C++ all over the place. Ja, richtig gelesen, die
suchen C++ Leute. Neben anderen Sachen
natürlich und oft stehen Java und C++ nebeneinander.
Wie ich schon sagte: Das richtige Tool für den
Job.
Der Omega13.
Es gibt auch noch andere Sprachen die nicht
kontextfrei sind. Natürlich ist C++ hier komplizierter
als zB Java und daher dauert auch die semantische
Analyse länger. Dafür bietet C++ auch Features
die andere Sprachen eben nicht haben.
Und wenn man diese Features zu nutzen weiss
(und auch in der richtigen Dosierung; wie bei Qt
zB) dann ist C++ einfach nur klasse.
Es kommt halt auf den Task an. Für etwas wo
Perl das perfekte Werkzeug ist nehm ich nicht
C++.
Der Omega13.
Oh du meine Güte wie kann man nur soviel Unsinn verbreiten. Wer erstrmal mit deiner Ausbildung fertig, dann reden wir weiter.
#include eine Precompiler Direktive???
Also wirklich, so etwas sollte man nach 2 Tagen C++ besser wissen:
http://www.cppreference.com/wiki/preprocessor/start
Der Rest deines geistigen Absturzes unterstützt nur meine These, dass du eben noch in den Kinderschuhen der Programmierung steckst.
Plus mach mal eine Nested-Class in C++, welche auf Variablen des umliegenden Scopes zugreift. Richtig, geht nicht. Ok, wird gehn mit Closures in C++0x (wohl 210x). Aber das implementieren so wenige Compiler das man's einfach noch nicht verwenden kann wenn man sich nicht total an einen Compiler binden will.
So ich als C++ und Python Heini sag mal...
Wenn es nicht gerade auf die Performance ankommt hat man mit PyQt einige Vorteile... Bis man in C++ seine Headerdateien fertig hat, hat man in Python schon das Programm fertig
Ich hab gehört, D oder OOC soll da voll die Kanone sein.
Versteh ich nicht ganz. Qt Creator 2.0 ist doch schon vor zwei Monaten erschienen.
Es geht ja auch um den Nachfolger 2.1.
Der Satz wurde mittlerweile ja schon entfernt. Vorher stand da so etwas wie "Dementsprechend wird Qt Creator 2.0 nicht erscheinen."
Ich freue mich schon auf die Final, dann wird es hoffentlich auch wieder Binarys für Linux geben und man muss sie sich nicht selber kompilieren - für alle anderen Systeme gibts ja fertige Pakete. Ich benutze gerne Qt, aber dass sie die Linux-Programmierer so stiefmütterlich behandeln finde ich echt fürn A***
Das ist Aufgabe der Distriibution und zugehörigen Unstable-Repos und nicht des Upstream-Projekts
> Linux-Programmierer so stiefmütterlich behandeln
> finde ich echt fürn A***
Was für eine dumme Aussage
Für die anderen OS gibt es die Binarys nicht weil sie bevorzugt werden sondern weil du unter Windows ein Hochschulstudium brauchst um das Zeug durch den Compiler zu bekommen.
Nein, es gibt im Gegenteil keine Binaries für Linux, weil es nur unter größten Schmerzen möglich ist, Binaries für Linux bereitzustellen. Das tun sich nur die wenigsten Upstreams an.
Hier gehts nicht um Clutter sondern um Qt.
Das Problem ist Linux-spezifisch, nicht Projekt-spezifisch (und wenn du schon dabei bist - bei C++ Projekten ist das Problem wegen fehlender ABI-Spezifikation tendentiell schwieriger als bei C Projekten).
Es gibt eine C++-ABI-Spezifikation, die zumindest vom Intel- und vom GNU-Compiler umgesetzt wird.
> Für die anderen OS gibt es die Binarys nicht weil sie bevorzugt werden sondern
> weil du unter Windows ein Hochschulstudium brauchst um das Zeug durch den
> Compiler zu bekommen.
Der Installer der Open Source Version von Qt unter Windows zieht Dir sogar den MinGW mit einem Click mit rein, konfiguriert und übersetzt alles.
Dafür brauchst Du nun wirklich kein Hochschulstudium.
Wenn Du Qt Creator verwendetst brauchst Du nicht mal $QTDIR, $QMAKESPEC und $MINGWDIR setzen.
Das ist nun schon alles recht DAU tauglich.
Das Übersetzen dauert halt etwas.
Bei Linux finde ich es ganz gut, dass man selber aus den Nokia/Trolltech Archiven übersetzt, weil man Qt dann auch in einem separaten Trolltech Verzeichnis drin hat und es keine Konflikte mit der standardmäßig installierten Qt Version gibt.
PS:
Ja das Verzeichnis heißt wirklich noch Trolltech und das wird hoffentlich auch so bleiben.
> Für die anderen OS gibt es die Binarys nicht weil sie bevorzugt werden sondern weil du unter Windows ein Hochschulstudium brauchst um das Zeug durch den Compiler zu bekommen
Wenn Sie meine Aussage schon als dumm hinstellen, dann sollten Sie nicht den Mund so voll nehmen und über Dinge reden, über denen Sie keinen Schimmer haben. Es ist nämlich absoluter Blödsinn, dass sich der Source von Qt für Windows schwieriger kompilieren lässt.
Und um noch mal auf meine ursprüngliche Aussage zu kommen: Aus meiner Sicht ist es extrem unschön, dass SDKs für Linux nur für Finalversionen angeboten werden, weil das Kompilieren (bei mir) Stunden dauert, während das Runterladen und Installieren eines SDKs für Linux nur Minuten dauert. Mich hält das jedenfalls davon ab neuere Versionen wie den jetzt erschienenen RC zu testen.
> Mich hält das jedenfalls davon ab neuere Versionen wie den jetzt erschienenen
> RC zu testen.
Dafür wäre es natürlich schön ein CVS|SVN|GIT Repository von Nokia angeboten zu bekommen (nur lese Zugriff)
Gibt es so etwas ?
Qt gibt's auf gitorious http://qt.gitorious.org/qt
Ah, Danke.
Als Mann des Ausgleichs würde ich gerne wissen, wie sehen denn die Fortschritte von GTK aus? Im Hinblick auf GNOME 3 tut sich da doch auch was oder?
Als Mann des Ausgleichs würde ich gerne wissen, wie sehen denn die Fortschritte von GTK aus? Im Hinblick auf GNOME 3 tut sich da doch auch was oder?
Alle mit deprecated gekennzeichneten Funktionen werden entfernt. Außerdem gibt es folgende neuen Features:
Bei Gnome 3 werden dann alle Applikationen entfernt, die noch Funktionen verwenden, die als deprecated gekennzeichnet sind. Außerdem werden die oben aufgelisteten neuen gtk-Features verwendet.
Sie haben weiter zurückgerudert. GNOME 3 wird wohl beides beinhalten: GNOME 2 mit GTK 2 und GNOME 3 mit GTK3. Wenn die Hardware es unterstützt wird GNOME 3 verwendet ansonsten gibt es GNOME 2 als Fallback. So macht es jedenfalls Fedora (Quelle: http://fedoraproject.org/wiki/Features/Gnome3). Ubuntu wird nur GNOME 2 und nicht GNOME 3 ausliefern um diese Inkonsistenz zu vermeiden. Ist mir nicht bekannt wie Suse und debian das Problem lösen wollen aber sie werden sich wohl für den Fedora oder den Ubuntu Weg entscheiden müssen.
Also ist GNOME 3 keine Weiterentwicklung sondern ein Fork von GNOME? Ich dachte die hätten nicht soviele Entwickler, dass Sie sich das leisten können....
Deine Quelle gibt den Stand der Aufnahme von GNOME 3 in die Fedora Repos wieder. Ich kann da nicht rauslesen, dass Fedora GNOME 2 als Fallback mitliefern will - es wird lediglich nicht die GNOME Shell verwendet, sondern das "klassische" Interface (das es ebenfalls in Version 3 gibt). Mit GNOME 2 hat das erstmal nix zu tun. Schon gar nicht kann man aus der Quelle rauslesen, was Upstream GNOME macht.
Nein, bei GNOME gibt es keine Inkonsistenz. Das Problem von Ubuntu ist anderer Natur. Sie haben nicht genug Platz, um GTK+ 2 und GTK+ 3 parallel auf ihre Installations-CD zu packen. Da einige wichtige Nicht-GNOME Programme noch GTK+ 2 verwenden (z.B. Firefox und Openoffice), haben sie jetzt ein Problem. Welche Lösung es dafür geben wird (GNOME 2 weiterverwenden, Firefox/Openoffice bei der Portierung helfen, GNOME Entwickler überzeugen, ihre neuen Programm-Versionen compile-zeit-optional auch mit GTK+ 2 laufen zu lassen, ...) wird sich erst noch zeigen.Ich denke, da musst du wo anders fragen, wenn du kompetente Antworten bekommen möchtest, nicht in einem Qt-Forum.
Seit wann ist pro-linux ein Qt Forum? Das wäre mir neu.
http://julus.meinbrutalo.de/