3. C++ 0x

C++ 0x

  • M

    Hi,

    wie stehts derzeit um C++ 0x? Wo kann man sich Informationen über den aktuellen Verlauf besorgen? Welches sind die wichtigsten Änderungen und was hättet ihr gerne noch drin?

    Ich persönlich wünsche mir erstmal ein einheitliches API. Ich hätte schon längst Oberflächen mit C++ gestaltet (hab nur ein bisschen mit der WinAPI gemacht), wenns was einheitliches gäbe. So bleib ich lieber bei der Konsole.

    Über Threads kann ich nichts sagen, weil ich die noch nie benutzt habe.

    Ne Typidentifikation ist nur selten hilfreich, aber wenn ich sie brauche, dann will ich sie auch. Also rein damit.

    Ne vollständige Unicode-Unterstützung wie in Java brauch ich nicht. Wenn ich Code von nem Chinesen weiterentwickeln soll, will ich auch die Variablennamen lesen können 😉 Für ofstream wärs dennoch wahrscheinlich nützlich, Unicode für die Zukunft zu unterstützen.

    Das sind so die Sachen, die mir spontan einfallen.

    0
  • O

    schau mal genau einen thread weiter unten 🙄

    //edit k wolltest unbedignt nen neuen öffnen 🙄

    0
  • ?

    wassn C++0x?

    0
  • M

    otze: Der andere Thread hat mich nur beflügelt endlich einen zu dem Thema zu eröffnen 😉

    Es spricht doch vieles dafür, einen neuen zu öffnen. Der alte ist veraltet, vieles hat sich verändert, manche Links gehen nicht mehr, es fehlt durch die Weiterführung von einem nicht mehr vorhanden Thread einfach der Zusammenhang.

    ***: C++ 0x wird der neue C++-Standard sein.

    0
  • N

    Michael E. schrieb:

    Ich persönlich wünsche mir erstmal ein einheitliches API. Ich hätte schon längst Oberflächen mit C++ gestaltet (hab nur ein bisschen mit der WinAPI gemacht), wenns was einheitliches gäbe. So bleib ich lieber bei der Konsole.

    Standard-C++ wird niemals ein GUI-Toolkit haben, sonst wäre es ja nicht mehr plattformunabhängig. 🙄

    0
  • N

    Mal ganz davon abgesehen das ich es auch nicht für sinnvoll halte ein gui-toolkit in den Standard einzubauen, es gibt doch immer Plattformabhängige Teile in der standardbibliothek (z.B. filestreams), oder?

    0
  • T

    ness schrieb:

    Mal ganz davon abgesehen das ich es auch nicht für sinnvoll halte ein gui-toolkit in den Standard einzubauen, es gibt doch immer Plattformabhängige Teile in der standardbibliothek (z.B. filestreams), oder?

    Außer der option ios::binary würde mir da gerade nix einfallen. Auf die sollte man aber auch verzichten.

    mfg

    0
  • N

    Was ich damit sagen wollte ist, dass es doch eigentlich egal ist ob code Plattformabhing ist, wenn es nur eine, auf allen Plattformen vorhandene, gleichbleibende Schnittstelle gibt. Als Programmierer kann es einem doch mehr oder weniger egal sein wie etwas erledigt wird, interessant ist das was...

    0
  • L

    ehm.. ich weis nicht ob diese Frage schon gestellt wurde
    aber wann ist dieser standard eigentlich dann vorgeschrieben, also wie lange dauert das noch?

    0
  • ?

    ca. 2008

    0
  • N

    ness schrieb:

    Was ich damit sagen wollte ist, dass es doch eigentlich egal ist ob code Plattformabhing ist, wenn es nur eine, auf allen Plattformen vorhandene, gleichbleibende Schnittstelle gibt.

    GUI-Zeugs kann aber nicht plattformunabhängig sein, da nicht alle Plattformen, auf denen C++ läuft, überhaupt Grafik-Unterstützung haben.

    leo aka qsch: C++0x steht für das Veröffentlichungsjahr. Man hat sich also nur auf <2010 festgelegt.

    0
  • A

    Bei den GUIs gibts ja auch noch ein Problem, das nicht alle GUIs das gleiche Bedienkonzept haben. Wenn ich mir MacOS, RISC OS und Windows anschaue, gibts da schon unterschiede: Windows hat zu jedem Fenster eine eigene Menuleiste für Pulldown-Menus. MacOS hat eine globale Menuleiste für Pulldown-Menus. RISC OS hat _garkeine_ Menuleiste für Pulldowns, die haben seit 1986 ausschliesslich Popup-Menus (Kontextmenus) - praktisch die Erfinder. Hat MacOS eigentlich Popup-Menus?

    Und das ist nur der Unterschied was die Menus angeht von drei GUIs. Und es gibt noch viele andere GUI-Konzepte, die es "besser" machen wollen. Wie soll man da eine einheitliche API konzipieren? Man müsste einen gemeinsammen Nenner finden, was wieder den jeweiligen GUIs nicht gerecht wird. Ergo würden nicht alle die API benutzen.

    Ich finde es schon OK wie es ist. Schlimm finde ich nur, das viele glauben, das es für C++ nur die MFC gibt. Was C++ leider einen schlechten Ruf bzgl. GUI-Programmierung gibt. 😞 Dabei gibt es sehr schöne GUI-Libraries, wie GTKmm oder Qt, die ähnlich intuitiv zu programmieren sind wie Javas SWING.

    Stichwort Swing: Sollen mal nicht alle glauben, das das sooo super ist. Warum gibt es denn mittlerweile SWT, welches nur nativ genutzt werden kann? Weil Swing zwar einheitlich ist, aber nicht wirklich 100% nativ ist. Man sieht sehr schön an diesem Beispiel, das uns eine GUI-API im Standard vielleicht helfen würde, aber es würde immer der Drang nach einer API geben, die auch die native GUI ausnutzen kann.

    0
  • M

    terraner schrieb:

    Außer der option ios::binary würde mir da gerade nix einfallen. Auf die sollte man aber auch verzichten.

    Was? Du willst auf ios::binary verzichten 😕

    Artchi: Dann wünsch ich mir aber wenigstens eine gemeinsame Schnittstelle für die wichtigsten Betriebssysteme. Damit könnt ich gut leben 🙂 Ich weiß nicht, inwieweit das machbar ist, aber bei Windows, Linux und Mac OS dürfte man doch ziemlich weit kommen.

    0
  • ?

    Wie war nochmal der Link zu den Papers?

    0
  • N

    nman schrieb:

    GUI-Zeugs kann aber nicht plattformunabhängig sein, da nicht alle Plattformen, auf denen C++ läuft, überhaupt Grafik-Unterstützung haben

    Ja, klar, aber wer versucht auf so nem systhem ein grafisches programm zu kompilieren 🙄 . Man könnte ja ne Abfrage einbauen, const bool has_gui und dann mit template-spezialisierung arbeiten...

    0
  • R

    GUIs gehören einfach nicht in den C++ Standard. GUIs sind zu groß, kompliziert und uneinheitlich.

    Threads und Sockets sollten aber definitiv in den Kernel.

    Was ich gern hätte, wären Named-Template-Parameter

    //Beispiel:

template<typename A=baz,typename B=foo,typename C=bar>
struct moep { };

moep<B=int,A=double> klack;

    Ansonsten sieht das, was man auf dieser Standardseite findet relativ gut aus.

    0
  • ?

    Aber wenn GUIs nicht reinkommen dürfen (bin ich auch der Meinung), aber warum dann Threads und Sockets? Haben doch auch nicht alle Betriebsysteme/Plattformen.

    0
  • N

    @Kingruedi: was nützt das?

    0
  • R

    @neu hier

    Die sollten dann eben in einen Teil der Standardlibrary kommen, der nicht zwangsmäßig implementiert werden muss. Aber diese Dinge sind mehr lowlevel und lassen sich eher vereinheitlichen, als GUIs.

    ness schrieb:

    @Kingruedi: was nützt das?

    Named-Template-Argumente? Das bringt etwas, wenn man viele Template-Parameter mit default Werten hat. Siehe

    template<class A=Aa,class B=Bb,class C=Cc /*...*/>
struct moep { };

    wenn du jetzt C setzen willst, dann musst du erst A und B belegen, dass zerstört ja das Konzept der default-Werte IMHO.

    0
  • A

    neu hier schrieb:

    Aber wenn GUIs nicht reinkommen dürfen (bin ich auch der Meinung), aber warum dann Threads und Sockets? Haben doch auch nicht alle Betriebsysteme/Plattformen.

    Weil das Konzepte sind, die überall gleich aussehen, also die Definition. OK, jedes OS kann letztendlich die Threads anders implementieren, aber heraus kommt das selbe: mehrere Programmteile laufen parallel ab. Bei einer GUI gibt es solche Definitionen nicht, wie man an meinem oben aufgeführten Beispiel sehen kann.

    Auch Sockets sind, bedingt durch den Internet-Standard, gleich: es geht was raus, und es kommt was rein. Da kann niemand dran rum rütteln, an der Definition. Ist bei den GUIs nicht so, da kann jeder was anderes machen.

    0
Anmelden zum Antworten