Nächster C++ Standard in 2009?
-
Yo, wirklich sehr schnell.
Ich hoffe die schaffen es dann wenigstens Threads und Networking bzw. wenigstens Sockets rein zu bringen. Aber da träum ich wohl zu viel, gell? 
-
@Artchi: Willst du C++ zu einer Art Java ohne Plattform drunter ausbauen? Weitere Libs die sich toll anbieten würden: GUI, ein HTTP-Server und eine abstrakte DB-Anbindung.
MfG SideWinder
-
HTTP-Server?
-
Ist das hier der offizielle Wunschthread?
Dann will ich ein ueberarbeiteten std::string 
-
Langsam spiele ich mit dem Gedanken nicht mehr von C++0x zu sprechen sondern von C++xy. Es muss ja nicht mehr viel schief gehen damit die bei 2010 sind.
-
Ben04 schrieb:
Langsam spiele ich mit dem Gedanken nicht mehr von C++0x zu sprechen sondern von C++xy.
Wozu? Mach es doch so wie es Sutter in seinem aktuellen CUJ-Artikel vorschlägt:
[...]we can always claim it's still "C++0x" but "x" just turned out to be a hex digit.
-
Ben04 schrieb:
Langsam spiele ich mit dem Gedanken nicht mehr von C++0x zu sprechen sondern von C++xy. Es muss ja nicht mehr viel schief gehen damit die bei 2010 sind.
Es wurde doch gesagt 2009. Wie kommst du jetzt auf 2010?
-
wie meinen? schrieb:
HTTP-Server?
Mein Posting war ironisch gemeint, ich bin nicht dafür einen HTTP-Server in die C++-Standard-Library zu verfrachten
@Hume: Hrhr, der Trick war mir nicht bekannt *g*
MfG SideWinder
-
So, laut diesem Dokument des C++ Standard Committees werden noch Vorschläge und Angebote zu folgenden Bereichen angenommen:
- Unicode
- XML und HTML
- Networking
- Usability for novices and occasional programmersDie Angebote können z.B. fertige High-Level Libraries zu den genannten Punkten sein oder komplett neue Vorschläge für den täglichen Gebrauch.
The two schedules are decoupled, but it is currently expected that TR2 will be published after C++0x.
Man, wann sollen die Dinger denn rein kommen??? Vorallem Unicode ist doch mega wichtig. Unicode werden wir also wohl in C++ erst frühestens 2010 bekommen???
Naja, wenigstens haben wir Zeit vielleicht als Community was zu machen? Siehe das hier:
Proposals for TR2 library extensions must be received by October 1, 2006.
-
Edit: Was fällt dir ein mein Posting sinnlos zu machen in dem du das Zitat+Kommentar wieder rausnimmst? :p
C++ hat keine Chance auf dem Markt wo C# und Java sich die Köpfe einschlagen, da helfen auch keine TCP/IP-Sockets im Standard (mal ganz abgesehen vom armen Toaster auf dem weiterhin Embedded C programmiert werden muss).
Ich finde man sollte sich weiterhin auf eine möglichst breite Linie konzentrieren. Eine Sprache eben, mit der man alles programmieren kann - was zwangsläufig dazu führt, dass es keine GUI-Library geben kann.
Im neuen Standard wären eine breitere Algo-Library ein schönes Pointer-Wrapper-Konzept, etc. schön (Viele Dinge, die man derzeit mit Boost o.Ä. holen muss).
Die Einschränkung auf eine einzige GUI-Library halte ich da für verkehrt. Das schränkt sofort die breite Sprache auf ein paar dutzend Plattformen ein. Natürlich kann man C++ solange trimmen bis ich schneller eine GUI basteln kann als mit C# - die Frage ist nur: Wieso nehm ich dann nicht gleich C#?
So. Alle Angaben ohne Gewähr
MfG SideWinder
-
Sorry, SideWinder. Hab nicht gewusst das du noch wach bist.
Für die anderen: habe SideWinders Frage zitiert, ob ich C++ zu einem Java ohne Platform machen will. Wobei ich der Meinung bin, das z.B. Networking wichtig im C++ Standard ist und das Gegenargument des Toasters nicht zählt.
SideWinder! Eine GUI fordere ich ehrlich gesagt nicht unbedingt, das wünscht sich Bjarne! Was er auch offiziell als Wunsch eingereicht hat. (cool das man als C++-Erfinder einen Wunsch einreichen muß, hihi) Aber Bjarne will mehr eine abstrakte API, aus der sich das Look&Feel der GUI nicht "ersehen" lässt. So hab ich das verstanden. Und da scheint der Knackpunkt zu sein: wie macht man sowas?
Ich bin aber der festen Überzeugung das Sockets bzw. Networking rein muß. Denn das ist nun wirklich nicht Platformspezifisch. Und wenn man bedenkt, das selbst ein Kühlschrank, eine Mikrowelle und vielleicht sogar ein Toaster (ja!) vernetzt werden soll (wer kennt nicht die damaligen Java-Visionen?), dann ist einfach sowas nötig.
Zu dem Pointer-Wrapper: meinst du damit z.B. die boost::shared_ptr? Die sind ja jetzt im TR1 drin, wenn ich es richtig verstanden habe und kommen somit spätestns 2009 raus. Genau das gleiche mit Regex u.a. Sachen aus Boost.
-
Artchi schrieb:
Aber Bjarne will mehr eine abstrakte API, aus der sich das Look&Feel der GUI nicht "ersehen" lässt. So hab ich das verstanden. Und da scheint der Knackpunkt zu sein: wie macht man sowas?
So wie Swing, mit plugable Look & Feels.
-
Neee, das hat ja nichts mit der API zu tun. Sondern eher solche Sachen wie, das z.B. MacOS keine rechte Mousetaste hat usw. Halt schon rein konzeptionelle Dinge, also Look&Feel das sich schon an Mouse und Keyboard bemerkbar macht oder z.B. das es ja Systeme gibt (wie RISC OS von Acorn!) die keine Pulldown-Menus kennen. Da würde sich eine Pulldown-Klasse nicht so gut machen, weil es das nicht zwingend unter allen System gibt (RISC OS kennt nur Popup-Menus. RISC OS hat nur Popup seit dem ersten Tag, 1986!).
Das Look&Feel von Java ist ja eher ein Skin den man wechseln kann, ändert nicht wirklich was am (G)UI-Konzept. (auch wenn dies bei Swing programmatisch gelöst wurde, was heute auch nicht mehr schlau ist).
-
Das tolle an abstrakten Libraries ist, dass man sie erst wieder nicht benutzen kann. Wenn eine GUI-Library endlich gtkmm/MFC/QT/etc. vereinen soll dann komplett - nur leider halte ich diesen Schritt für völlig falsch. Eine abstrakte Basis hingegen bringt dem Anwender wiederrum nichts, braucht er doch wieder etwas Externes.
Von Sockets hingegen hast du mich jetzt schon fast überzeugt, auch wenn ich eine Beschränkung auf TCP/IP wiederrum zu beschränkend für eine Sprache wie C++ halte.
Sorry, SideWinder. Hab nicht gewusst das du noch wach bist.
Mit mir musst du zu jeder Tageszeit rechnen :D;)
Edit: "MacOS keine rechte Mousetaste hat usw.", was ja nun afair nicht mehr stimmt.
MfG SideWinder
-
Artchi schrieb:
Neee, das hat ja nichts mit der API zu tun. Sondern eher solche Sachen wie, das z.B. MacOS keine rechte Mousetaste hat usw. Halt schon rein konzeptionelle Dinge, also Look&Feel das sich schon an Mouse und Keyboard bemerkbar macht oder z.B. das es ja Systeme gibt (wie RISC OS von Acorn!) die keine Pulldown-Menus kennen. Da würde sich eine Pulldown-Klasse nicht so gut machen, weil es das nicht zwingend unter allen System gibt (RISC OS kennt nur Popup-Menus. RISC OS hat nur Popup seit dem ersten Tag, 1986!).
Das Look&Feel von Java ist ja eher ein Skin den man wechseln kann, ändert nicht wirklich was am (G)UI-Konzept. (auch wenn dies bei Swing programmatisch gelöst wurde, was heute auch nicht mehr schlau ist).
Ok. Dann bin ich auch mal gespannt.
-
Warum müssen jetzt unbedingt Sockets in den Standard? Braucht man doch in der Praxis ziemlich selten.
-
GUIs sind wirklich nichts für den C++ Standard, da sie viel zu sehr von aktuellen Trends und den unterliegenden Systemen abhängen. Da ist es imho okay eine third-party Library zu benutzen.
Allein MacOSX und Windows lassen sich nicht so leicht über einen Kamm scheren. C++ will aber nicht nur Desktops abdecken, nur wie vereint man die GUI API eines Handys mit der von Windows?
Das ist alles zu inkompatibel, als das man ein alles abdeckendes Konzept finden kann oder die Library würde wieder zu wenig abdecken. Außerdem braucht eine gute GUI Library viele weitere Tools (Designer etc), die müssten dann auch in den Standard!
-
man könnte doch ACE in den standart tun
-
Eine abstrakte Basis hingegen bringt dem Anwender wiederrum nichts, braucht er doch wieder etwas Externes.
Das schon, aber die Schnittstelle ist erst mal standardisiert. Ich glaube wenn es erst mal eine Standardschnittstelle giebt kann man auch drauf warten, das innerhalb kürzester Zeit die ersten Implementierungen für verschiedene Plattformen auftauchen.
GUIs sind wirklich nichts für den C++ Standard, da sie viel zu sehr von aktuellen Trends und den unterliegenden Systemen abhängen. Da ist es imho okay eine third-party Library zu benutzen.
Sehe ich im Prinzip auch so, deshalb gefällt mir auch das Konzept, wenigstens die Schnittstelle zu standarsisieren um zumindest eine Basis GUI Systemunabhängig realisieren zu können.
-
SideWinder schrieb:
Ich finde man sollte sich weiterhin auf eine möglichst breite Linie konzentrieren. Eine Sprache eben, mit der man alles programmieren kann - was zwangsläufig dazu führt, dass es keine GUI-Library geben kann.
Ich faends sinnvoll, die Standard-Library aufzuspalten: z. B. in ein "Core"-Packet mit Dingen, die auf jeder Plattform (und jedem Haushaltsgeraet
)sinnvoll sind (die ganze STL mit Containern & Algorithmen), und ein erweitertes, das dann Threads, Sockets und eben evtl. auch eine GUI enthaelt.