Nächster C++ Standard in 2009?
-
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.
-
Ich verstehe ehrlich gesagt nicht, warum die Standard-Lib so abgespeckt sein muss, damit sie auch auf einem Toaster oder ähnlichem läuft. Wieso gibt es nicht eine Basis-Edition, die bspw. Algorithmen und Container-Klassen enthält, dann gibt es eine Network-Edition, die Netzwerkfunktionalität anbietet, dann gibt es eine Desktop-Edition, die GUI-libs für PCs enthält, eine Handy-Edition, für eine GUI auf Handys, usw. Wo ist hier das Problem?
Muss einer auf einem 8-Bit Microcontroller mit 1Kbyte RAM programmieren, dann nimmt er halt die Basis-Edition, auf einem Desktop-PC nimmt er die Desktop-Edition.Ich will z.B. endlich mal lib-übergreifend die gleiche String-Klasse verwenden!
Ich meine, wieso gibt es dann überhaupt die Standardein- und -ausgabe im Standard. Auf Microcontrollern gibts sowas meist nicht...
Gruß mathik
-
Blue-Tiger schrieb:
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.Da haben wohl zwei Du... einen Gedanken gehabt
-
mathik schrieb:
Ich will z.B. endlich mal lib-übergreifend die gleiche String-Klasse verwenden!
Dass das schwer geht, liegt IMHO nicht direkt daran, dass die Standardbibliothek relativ klein ist. Ich sehe zwei technische Gründe:
- std::string ist schlecht designed, nicht Unicode-fähig (genauer gesagt nicht multibyte-fähig, die meisten Encodings für Unicode sind aber multibyte) und heute, wo sich nach 15 Jahren Unicode langsam durchzusetzen scheint, ist das Ding bald ncht mehr brauchbar.
- std::string ist ein template ohne standardisierte binäre Schnittstelle. Wenn ich eine DLL schreibe und compiliere und du sie nutzen willst, musst du meiner lib ein const char* übergeben, denn der std::string kann bei meinem Compiler völlig unterschiedlich aussehen. Lösen könnte man dieses Problem IMHO nur, wenn man eine exakte Byte-Repräsentation eines Strings vorschreibt (oder mit JIT-Compilierung ).
-
Optimizer schrieb:
...und heute, wo sich nach 15 Jahren Unicode langsam durchzusetzen scheint...
rofl
in deiner traumwelt vielleicht.
-
Gib mir doch mal Informationen, die mich das Gegenteil glauben lassen. Unter Linux-Systemen ist UTF-8 schon so lange der Standard, wie es standardmäßiger gar nicht mehr geht. Jeder Texteditor, jede Konsole, alles verwendet immer standardmäßig UTF-8.
Windows nutzt ab Version 2000 für die interne Repräsentation von Zeichenketten UTF-16 und alle API-Funktionen nehmen wchar-Strings. Die alten API-Funktionen, die ANSI-Strings fressen existieren noch, wandeln aber den String nur nach UTF-16 um und lassen dann die eigentliche Arbeit verrichten. Einzig und allein bei MacOS weiß ich es nicht so genau. Aber 95% der Betriebsysteme habe ich jetzt abgedeckt.
-
@TheBigW
Ja, aber wie willst du eine unabhängige Schnitstelle definieren?Ich seh keinen Weg, wie man eine GUI so in eine Programmiersprache integrieren kann, dass damit die Leute noch in 10 (oder 2) Jahren zufrieden wären.
Schaut euch doch mal Java an, da gibt es doch auch zig unterschiedliche Sachen und die Leute meckern regelmäßig über Java Desktopanwendungen. Und im Gegensatz zu Java ist C++ nicht so Trend gebunden (was bei der Standard Entwicklungszeit gar nicht möglich wär).
-
Vielleicht sollte man von dem Gedanken weg, das man die GUI programmieren muß? Der Trend geht doch eher dahin, das man die GUIs in (z.B.) XML bastelt. Auch was z.B. passieren soll, wenn einer der Knöpfe gedrückt wird, wird in der XML beschrieben. Dann wird einfach das Event (oder Signal, völlig Latte!) an die C++ Funktion bzw. Methode gefeuert, und erst dann kommt C++ ins Spiel. Halt bei Businesslogic und nicht beim GUI selbst.
Dann wäre es auch in 10 Jahren egal, ob es noch Knöpfe gibt. Dann muß man vielleicht nur die XML-Datei ändern.
Genauso arbeitet doch z.B. das ganze Mozilla-Framework, ein Praxisbeispiel wäre ja der Firefox. Die GUI ist in XML gebastelt und welche C++-Funktionen aufgerufen werden sollen, steht da auch drin.
MS will das ja auch einführen, nennt sich XAML, da soll dann jeder mit XAML schon fast ne komplette Windows-Anwendung zusammen schustern können.
Für Java gibts auch XML-GUI-Frameworks, aber dauert halt noch bis sich sowas durchsetzt.
Nur muß man dann natürlich wirklich komplett auf eine GUI-API verzichten, es muß halt so eine Engine sein die nur die XML-GUI liest und unter jedem OS die GUI zaubert.