Nächster C++ Standard in 2009?
-
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.
-
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.Meiner Meingung nach gibt es doch das bereits, für viele Spalten sogar : wxWidgets, QT, OpenGL, Allegro, ... Sie sind zwar meist nicht Standard in dem Sinn, dass sie in irgendeinem ISO Dokument festgelegt allerdings würde das auch nicht viel bringen. Sie sind portable soweit ihre Funktion auf der Zielplatform überhaupt möglich und sinvoll ist (Ein Toasterprogram braucht keine GUI auch wenn man einen Computer mit Bildschirm in einen Toaster bauen kann). Die Erhebung oder Dublizierung in den Sprachstandard würde nichts bringen.
Threads sind allerdings meiner Meinung nach ein Teil der Sprache und gehören deshalb in den Sprachstandard hinein.
-
Artchi schrieb:
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.
Eine reine XML-Gui wird dir aber absolut nichts weiterhelfen, denn irgendwie musst du doch wieder auf die einzelnen Komponenten
zugreifen können. Ansonsten würde es mit Ausgaben an den Benutzer nur sehr spärlich aussehen, man scheitert doch bereits
an dem bloßen Anzeigen einer MessageBox. Bzw. ein anderes Beispiel ist das Hinzufügen von Komponenten zur Laufzeit.Die Idee ansich ist ja ganz nett, allerdings ist so eine XML-Gui höchstens ein Aufsatz auf eine bestehende API.
-
Im Model View Konzept greif ich nicht auf die Komponenten zu, das sollte mittlerweile bekannt sein? Machen wir in unseren Java-Anwendungen zumindest nicht. Um einen Dialog (z.B. ja/nein-Frage) anzuzeigen, lade ich einfach eine entsprechende XML-Datei (ich nenn das jetzt einfach mal so) die angezeigt wird. Was technisch dabei in der Engine raus kommt, ist mir eigentlich egal, hauptsache sie erfüllt fachlich ihren Zweck.
Das letztendlich irgendwo irgendwie eine GUI-API (WindowsForms, GTK, X-Window etc.) benutzt wird, ist klar. Aber das ist ja auch nicht das Problem. Denn es geht ja nicht darum die APIs von Windows, MacOS oder KDE zu ersetzen! Es geht nur um einen Wrapper, wie es auch mit z.B. boost::thread der Fall ist. boost::thread benutzt auch nur die Windows-Threads oder unter Unix halt pthread. Aber mir als C++ler ist es egal was technisch am Ende raus kommt. Genau das gleiche soll hier mit der GUI passieren.
-
Der XML Ansatz ist für allgemeine GUIs nicht schlecht. GUIs lassen sich recht fix zusammen basteln und können denoch sehr flexibel an Kundenwünsche angepasste werden. Hier ist ein XML basierter Ansatz klar im Vorteil.
Allerdings bei spezielleren GUIs. Zum Beispiel ein Codeeditor. Ein Syntaxhighlighter der sich einer C++ Funktion bedient um die einzeln Passagen zu markiren könnte ich mir ja noch in XML vorstellen. Allerdings spätestens bei der Autovervollständigung wirst du dafür kein Widget ab Stange mehr haben. Hier muss man das Widget erste schreiben. Man kann nachher natürlich XML benutzen um es in die GUI einzufügen allerdings man kann keine Widgets in XML anpassen.
-
Ben04 schrieb:
(Ein Toasterprogram braucht keine GUI auch wenn man einen Computer mit Bildschirm in einen Toaster bauen kann).
Selbst der neueste Tchibo-Toaster hat ein Display... *schauder* Ich dachte, da steht ein UFO in der Küche
-
omfg. Es gibt wirklich immer weniger Zeug, was man einfach anschaltet und funktioniert. Wenigstens gehört meine Kaffeemaschine noch dazu.
-
Optimizer schrieb:
omfg. Es gibt wirklich immer weniger Zeug, was man einfach anschaltet und funktioniert. Wenigstens gehört meine Kaffeemaschine noch dazu.
Huch, die diversen Geräte, die ich kenne, also so etwas ähnliches wie http://www.eshoppen.de/shop/images/artikel/Cloer_Kaffeemaschine_5021.jpg sind alle sehr fehlerbehaftet und hochkompliziert in der Anwendung.
Fehler 1:
Wasser in Kanne, Pulver in Filter (-> in Haltevorrichtung), Kanne wird, ohne sie sachgerecht in den Wasserbauch der Maschine zu kippen, auf die Wärmestelle gestellt, Kaffeemaschine anschalten. Konsequenz: Wasser wird lauwarm.Fehler 2:
Wasser in Kanne, Pulver in Filter (-> in Haltevorrichtung), Kanne in Wasserbauch entleeren, Kanne nochmal mit Wasser befüllen, Kanne auf Wärmstelle platzieren, Kaffeemaschine anschalten. Konsequenz: Kräftiger Kaffeegeruch in Küche, Sauerei in der Nähe der Kaffeemaschine; der Kaffee in der Kanne bleibt allerdings eher dünn.Fehler 3:
Wasser in Kanne, Kanne in Wasserbauch entleeren, Kanne auf Wärmstelle platzieren. Konsequenz: Vergessen Kaffeefilter und -pulver zu tauschen. Sehr umweltfreundlich, Kaffee schmeckt aber eher dünn.Einmal habe ich auch gedankenverloren die volle Kaffeekanne nochmal unter den Wasserhahn gehalten. Den Filter einfach ganz zu vergessen ist dagegen eher normal (Konsequenz: Wasser wird heiß).
<eidesstattlich> Alle diese Vorfälle haben sich tatsächlich durch mich oder in meiner Gegenwart ereignet </eidesstattlich>
Vielleicht sind das zwar eher Fälle für menschliches Versagen, aber nur so viel zu der These, eine Kaffeemaschine "macht man an und sie funktioniert".
-
Daniel E. schrieb:
<eidesstattlich> Alle diese Vorfälle haben sich tatsächlich durch mich oder in meiner Gegenwart ereignet </eidesstattlich>
deswegen gibt es sekretärinnen, die können das viel besser als wir.
einen elegantern ausweg sah ich mal in frankfurt in nem unternehmen. chef kaufte kaffemaschine für 1200DM, wo man nur auf einen knopf drücken mußte und fertiger kaffe kam raus. das einzige, was noch an warung anfiel war, hin und wieder frischen kaffe einzufüllen und alten kaffe wegzuwerfen. und ich habe keine ahnung, wer das machte.
ich nehme auch ein wenig an, daß diese mega-maschine den zweck hatte, die leute davon abzuhalten, immer so lange in der kaffeküche zu verschwinden, aber naja, da ich lieber programmiere als kaffe koche, fand ich die maschine großartig.
-
Schlimm sind diese Espresso-Teile, wo man für jede halbe Tasse ein teures Tab in die Maschine schiebt und verbraucht. Ich vermute immer noch, dass das der Grund ist, warum die Firma, bei der ich Praktikum gemacht habe, pleite gegangen ist. Naja amsonsten ist es wohl meine Schuld.
-
hab ich was verpasst? wird die programmiersprache C++ nun auf C++0x umbenannt oder heisst der neue standard dann einfach C++0x wie er heute IEC:14882 heisst?
-
Hm, vergesst den Standard, falls der je erscheint, wird er das
reflektieren was man jetzt bräuchte, aber nicht das was
man 201x braucht, er wird genauso veraltet sein, wie er jetzt schon ist.
Es gibt ja jetzt schon genug Libraries die den Standard wunderbar ergänzen,
und ich brauche da keinen Guru der dann sagt "Boost ist jetzt auch Standard".
Im übrigen für Unicode gibts auch schon Libs, oder man geht gleich zu
den alles - in - einer - Library - Lösungen wie QT, GTKmm oder wxWidgets.phlox
-
volkard schrieb:
einen elegantern ausweg sah ich mal in frankfurt in nem unternehmen. chef kaufte kaffemaschine für 1200DM, wo man nur auf einen knopf drücken mußte und fertiger kaffe kam raus. das einzige, was noch an warung anfiel war, hin und wieder frischen kaffe einzufüllen und alten kaffe wegzuwerfen. und ich habe keine ahnung, wer das machte.
Ja, das ist prima. So ein Teil steht in der Firma, in der ich gelgegentlich arbeite, auf jeder Etage. Sehr praktisch. Nachfüllen wird vom Kantinen-Personal gemacht. Nur manchmal muß man den Trester leeren... da wird dann immer ausprobiert, wie lange die Maschine trotz Warnung doch noch Kaffee produziert.
-
@phlox
C++ arbeitet nach einem anderen Ansatz, als .NET oder Java. Auch 09 werden die nicht alles drin haben, was man für die C++ Programmierung braucht. Aber C++ wollte auch nie alles abdecken (oder willst du mir erzählen, dass die 98 nicht mit dem Erfolg von grafischen GUIs gerechnet hätten).huh? schrieb:
hab ich was verpasst? wird die programmiersprache C++ nun auf C++0x umbenannt oder heisst der neue standard dann einfach C++0x wie er heute IEC:14882 heisst?
Nein, C++ wird weiter C++ heißen. Das man das Jahr an die Programmiersprache hängt, um den Unterschied zwischen den Standards deutlich zu machen ist schon älter. Siehe Algol68 oä. Der Standard wird natürlich auch eine eigene ISO/IEC Nummer bekommen. C++09 (wenn er denn 2009 kommt), ist dann die umgangssprachliche Bezeichnung
