Nächster C++ Standard in 2009?
-
Eben. Wenn C++ auf den gleichen Zug wie Java und C# aufspringen möchte nur mit 10 Jahren Versatz, dann gibt es keinen Grund mehr C++ zu benutzen.
-
Mag sein, aber ein bisschen weniger minimalismus wäre schon schön. Ich finde es einfach blöd, für alles was außerhalb von I/O, Containern und Standardalgorithmen liegt, ne extra lib nehmen zu müssen, auch wenn boost sehr viel abdeckt. Deshalb muss man ja nicht gleich wie Java oder C# werden.
-
C# und Java sind eindeutig für den Plattform-Markt ausgelegt, TCP/IP-Sockets machen Sinn.
C++ hingegen hat für mich immer den Vorteil gehabt viel breiter zu sein. Warum also gerade TCP/IP-Sockets, nein wenn dann protokollunabhängige Sockets. Das wiederrum führt zu einer zu aufgeblähten Library die dann erst recht nieamnd mehr benutzen will wenn er nur TCP/IP benötigt. Letzten Endes landet man wieder wo man vorher war.
MfG SideWinder
-
Walli schrieb:
Eben. Wenn C++ auf den gleichen Zug wie Java und C# aufspringen möchte nur mit 10 Jahren Versatz, dann gibt es keinen Grund mehr C++ zu benutzen.
Das hört sich ja fast so an, als ob das Fehlen von vielen Dingen in der Standardbibliothek ein Pluspunkt für C++ ist. "Ein Grund, warum man C++ nutzt". Das muss man doch andersherum sehen. IMHO ist das momentan ein Grund, C++ nicht zu nutzen. Wenn C++ das beheben würde, dann würde es gegenüber .NET oder auch Java eine Schwachstelle beheben. ...und da sage ich "Besser spät als nie".
Artchi schrieb:
Gleichzeitig sagt er aber, das der einzige Hacken zur Zeit ist, das man keine allgemeingültige GUI-Lib designen kann, die allen Platformen gerecht wird. Weil das nur wieder der kleinste gemeinsame Nenner werden würde. Und nicht weil C++ auch auf einem Toaster laufen können soll, wie viele immer behaupten.
Genau das ist das Toaster-Argument. Man will allen Plattformen gerecht werden und nur das Minimum aller Plattformen als Grundlage für die Standardbibliothek nehmen.
Wenn eine Plattform für die GUI eine Komponente oder so nicht anbietet, könnte man doch einfach von der jeweiligen Realisierung der Standardbibliothek verlangen, dass die das selbst macht. Wer irgendwas plattformspezifisches machen will, kann dann ja immer noch eine externe Bibliothek nutzen.
-
Das hört sich ja fast so an, als ob das Fehlen von vielen Dingen in der Standardbibliothek ein Pluspunkt für C++ ist.
Assembler fehlt keine Socket-Library. C++ fehlt keine GUI-Library. Java fehlt keine Library für Satellitensteuerung. Ja ich sehe es als Pluspunkt das ich hier die freie Wahl habe.
MfG SideWinder
-
Was ist eignentlich so schlimm daran eine Biblotek zu nutzen? Es ist ja nicht so als wenn platformunabhänglige GUI Entwickelung nur in Java möglich wäre.
-
Gregor@Home schrieb:
Walli schrieb:
Eben. Wenn C++ auf den gleichen Zug wie Java und C# aufspringen möchte nur mit 10 Jahren Versatz, dann gibt es keinen Grund mehr C++ zu benutzen.
Das hört sich ja fast so an, als ob das Fehlen von vielen Dingen in der Standardbibliothek ein Pluspunkt für C++ ist. "Ein Grund, warum man C++ nutzt". Das muss man doch andersherum sehen. IMHO ist das momentan ein Grund, C++ nicht zu nutzen. Wenn C++ das beheben würde, dann würde es gegenüber .NET oder auch Java eine Schwachstelle beheben. ...und da sage ich "Besser spät als nie".
DER Grund C++ zu nutzen ist im Moment doch nur die breite Codebasis die vorhanden ist und der Mangel an etablierten besseren Sprachen. Vom Standardkommitee wird man in der Hinsicht GUI nicht viel erwarten können. Die sind eben zu langsam, aber durch die große Verbreitung von C++ hat man auch ohne Standard alles was man braucht, wenn auch nicht aus einer Hand.
-
SideWinder schrieb:
Das hört sich ja fast so an, als ob das Fehlen von vielen Dingen in der Standardbibliothek ein Pluspunkt für C++ ist.
Assembler fehlt keine Socket-Library. C++ fehlt keine GUI-Library. Java fehlt keine Library für Satellitensteuerung. Ja ich sehe es als Pluspunkt das ich hier die freie Wahl habe.
MfG SideWinder
Nun gut, aber dann stellen sich mir folgende Fragen:
1. In welche Richtung soll sich C++, dem Wunsch des ISO Komitees nach, dann entwickeln?
2. Welche Auswirkungen hat das auf C++ (besonders auf Einsatzgebiet und Verbreitung), wenn die Standardlib nicht auf dem Niveau von Java ist bzw. einfach mal ein paar wichtige Features reinkriegt?EDIT: Rechtschreibfehler korrigiert
-
Gregor@Home schrieb:
Artchi schrieb:
Gleichzeitig sagt er aber, das der einzige Hacken zur Zeit ist, das man keine allgemeingültige GUI-Lib designen kann, die allen Platformen gerecht wird. Weil das nur wieder der kleinste gemeinsame Nenner werden würde. Und nicht weil C++ auch auf einem Toaster laufen können soll, wie viele immer behaupten.
Genau das ist das Toaster-Argument. Man will allen Plattformen gerecht werden und nur das Minimum aller Plattformen als Grundlage für die Standardbibliothek nehmen.
Wenn eine Plattform für die GUI eine Komponente oder so nicht anbietet, könnte man doch einfach von der jeweiligen Realisierung der Standardbibliothek verlangen, dass die das selbst macht. Wer irgendwas plattformspezifisches machen will, kann dann ja immer noch eine externe Bibliothek nutzen.
Nein, ebend nicht. Ich entwickel seit 5 Jahren mit Java Client-Anwendungen, und jedesmal fragen mich die Benutzer und Kunden "Warum ist das nicht so wie ich es von Windows her kenne?" "warum ist dieses Häckschen nicht grau, obwohl das Menuitem grau ist?" Andauernd bekommen wir einfachste Unterschiede, die in Swing normal sind, an den Kopf geworfen. Und wir dürfen einen Workaround programmieren -> nervig!
Ich bin Profi, mich stört es nicht wenn mal eine GUI etwas anders aussieht oder sich anders verhält. Aber die DAUs, die sich Dipl.-Ingeneure nennen, und unsere JavaClients benutzen, raffen das nicht. Und DAS würde C++ nicht viel helfen, wenn die GUI-Lib nicht alle Features eines GUIs unterstützt.
Was ist z.B. mit MacOS? Die haben doch serienmäßig nur eine Mousetaste (ich weiß, es gibt auch andere). Aber wie designe ich das in der Library? Soll ich mich an den Mac orientieren? Dann meckern die Windows-User, das sie keine 2. oder 3. Taste benutzen können. Ist in der Lib support für 3. Taste da, werden sich die Mac-User aufregen, wenn ich mein Programm darauf compiliert habe.
-
Walli schrieb:
DER Grund C++ zu nutzen ist im Moment doch nur die breite Codebasis die vorhanden ist und der Mangel an etablierten besseren Sprachen. Vom Standardkommitee wird man in der Hinsicht GUI nicht viel erwarten können. Die sind eben zu langsam, aber durch die große Verbreitung von C++ hat man auch ohne Standard alles was man braucht, wenn auch nicht aus einer Hand.
Also ich pers. benutze C++ nicht wegen der großen Code-Basis, sondern weil es mir Sprach-Features bietet, die ich woanders vermissen. Ich hab mir an den Kopf gefasst, als im Java-Spektrum-Magazin das Tool CaesarJ vorgestellt wurde. Wie toll man damit viele Wartungsprobs umgehen kann und viel flexibler wird. Am Ende stellt sich, nach dem studieren des CaesarJ-Docs, haraus, das CaesarJ Mehrfachvererbung für Java anbietet, in dem es einen Pre-Compiler (ich nenne es jetzt mal so) anbietet. D.h. CaesarJ ist einfach eine Art Java-Sprach-Extension, die die Sprach-Defizite ggü. C++ kompensiert.
So wie Bjarne Stroustrup so schön gesagt hat: was stört die Leute an den vielen C++ Sprachfeatures? Keiner muß sie benutzen, aber wenn sie mal gebraucht werden, kann man sie einsetzen.
Bei Java wiederrum mag ich, das ich gleich eine umfangreiche Library habe. Auch wenn sie nicht perfekt ist. Aber ich kann gleich loslegen und muß nicht groß Libs suchen und einrichten.
Wie gesagt, das ISO Kommittee wünscht sich für den TR2 z.B. eine Network- und XML-Libarary. Ich finde, das ist doch mal eine Aussage!
Nur muß das die C++ Community machen, das Kommittee hört sich die Vorschläge nur an und stimmt dann darüber ab, ob der Vorschlag aufgenommen wird.
-
Dafür haben sie doch - das solltest du doch eigentlich kennen - die Look&Feels eingebaut in Java Swing eingebaut. Wenn du natürlich die Java-Oberfläche statt Windows-Native verwendest wird das Häkchen nicht grau
MfG SideWinder
-
Also ich habe natürlich Windows-L&F, und das Häckchen ist nicht grau. Kann sein das es in Java 1.5+ behoben wurde, in 1.4 ist es einer von vielen Defiziten. Woebei das mit dem Häckchen eines von vielen Beispielen ist.
Wo sind z.B. die Popups-Menus für die Eingabefelder? (gehört auch zum Look&Feel!) Darf ich auch selber proggen oder mir im Netz eine Lib suchen. Wenn ich alle Defizite aufzählen würde, könte ich ein Buch schreiben.
-
Was spricht gegen JPopupMenu? Naja verlieren wir uns nicht in den Details, Java 1.4.x ist sowieso seit über einem Jahr nicht mehr Stand der Technik. Das sind zudem nicht alleine javaspezifische Probleme, du wirst ähnliche Probleme mit QT und anderen plattformübergreifenden GUI-Libraries haben.
MfG SideWinder
-
SideWinder schrieb:
Was spricht gegen JPopupMenu?
Ja, hab ich gesagt: selber machen oder lib suchen. Aber warum hat Javas JTextfield kein Popup mit Cut, Copy & Paste???????? Ich muß jedem User sagen, das er mit Strg+V einen Text einfügen kann, wenn ich mal wieder einen Anruf erhalte. Das ist doch der Witz an der Sache, den Bjarne Stroustrup meint!
Naja verlieren wir uns nicht in den Details, Java 1.4.x ist sowieso seit über einem Jahr nicht mehr Stand der Technik.
Ja, wir konnten leider noch nicht auf 1.5 umsteigen, weil uns unsere Anwendung manchmal unter 1.5 einfriert.
Unter 1.4 läufts soweit. Müssen erstmal den Bug finden. Egal...Das sind zudem nicht alleine javaspezifische Probleme, du wirst ähnliche Probleme mit QT und anderen plattformübergreifenden GUI-Libraries haben.
Jetzt hast du haargenau das gesagt, was Bjarne auch sagt. Die allgemeingültigen Libs haben solche Probs, und unter C++ wäre es nicht anders. Genau das will man nicht. Weil am Ende eh jeder z.B. in seiner Windows-Applikation z.B. MFC benutzen würde, wenn er nicht gerade platformunabhängig sein braucht.
-
Artchi schrieb:
Also ich habe natürlich Windows-L&F, und das Häckchen ist nicht grau. Kann sein das es in Java 1.5+ behoben wurde, in 1.4 ist es einer von vielen Defiziten. Woebei das mit dem Häckchen eines von vielen Beispielen ist.
Wo sind z.B. die Popups-Menus für die Eingabefelder? (gehört auch zum Look&Feel!) Darf ich auch selber proggen oder mir im Netz eine Lib suchen. Wenn ich alle Defizite aufzählen würde, könte ich ein Buch schreiben.
Ich sehe das Problem da so. Da versucht man, wie etwas anderes auszusehen und schafft das nicht bis in alle Details. Das fällt den Leuten dann auf. Die Lösung ist einfach. Nutze eben NICHT das Windows L&F. Dann ist von Anfang an klar, dass das in dem Programm anders ist. Unter Windows haben ja auch eine ganze Menge Programme ein individuelles Aussehen und es macht keinem etwas aus. Insofern sehe ich da kein Problem.
-
@Gregor: Das wäre ein Schritt in die falsche Richtung. Wenn Windows etwas geschafft hat, dann ein einheitliches Fenster-Format. Anwendungen die dauernd ihr eigenes Süppchen kochen kann ich nicht ausstehen. Das fängt bei der Belegung von Shortcuts an und hört nicht zuletzt beim Popup-Menü vom Edit-Feld auf.
Weil am Ende eh jeder z.B. in seiner Windows-Applikation z.B. MFC benutzen würde, wenn er nicht gerade platformunabhängig sein braucht.
Jop, und bevor man selbst auch noch eine Library hinuzfügt, die dann nur eine von vielen mit dem Ziel den Rest zu erstzen ist, baut man am Besten gar keine.
Ja, wir konnten leider noch nicht auf 1.5 umsteigen, weil uns unsere Anwendung manchmal unter 1.5 einfriert.
MfG SideWinder
-
Artchi schrieb:
Walli schrieb:
DER Grund C++ zu nutzen ist im Moment doch nur die breite Codebasis die vorhanden ist und der Mangel an etablierten besseren Sprachen. Vom Standardkommitee wird man in der Hinsicht GUI nicht viel erwarten können. Die sind eben zu langsam, aber durch die große Verbreitung von C++ hat man auch ohne Standard alles was man braucht, wenn auch nicht aus einer Hand.
Also ich pers. benutze C++ nicht wegen der großen Code-Basis, sondern weil es mir Sprach-Features bietet, die ich woanders vermissen.
Den Teil mit "und der Mangel an etablierten besseren Sprachen" hast du überlesen, oder?
-
@Walli! Ob du es glaubst oder nicht, hab ich tatsächlich nihct registriert. Sorry!
Dann nimm mein Antwort-Posting als Ergänzung auf.
-
C++ ist wirklich eine geniale Sprache, von den Möglichkeiten und der Performance. Aber der Standard ist einfach nur *hust*. Die Methodennamen sind oft nicht gut gewählt, Standardausgabe mittels cout ist alles andere als effektiv und die string Klasse ist auch nicht das Gelbe vom Ei.
Boost ist schon ein guter Ansatz, Qt zeigt auch wie man etwas machen könnte. Was jetzt nocht fehlt, wäre ein Projekt ähnlich Boost welches eine Art C++ Desktop Umgebung bildet. Mit den derzeitigen Möglichkeiten und der Geschwindigkeit des neuen Standards wird C++ gegenüber Java und C# immer weiter an Boden verlieren.
BTW: Ich meine mal gelesen zu haben, dass Volkard an einer Reimplementierung von cout arbeitet? Das wär ja schon mal ein Anfang
-
-Marc- schrieb:
...
Mit den derzeitigen Möglichkeiten und der Geschwindigkeit des neuen Standards wird C++ gegenüber Java und C# immer weiter an Boden verlieren.
...Behauptung, oder?
Abwarten wie es sich entwickeln wird.
mfg
v R