3. C++ 0x

C++ 0x

  • 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
  • ?

    Gibts in DOS Threads? hmmmmmm?

    0
  • A

    Kann man in DOS problemlos implementieren. "Threads" konnte selbst mein C64, wurde nur halt mit Interrupts der CPU gelöst. Aber hat funktioniert! Alle Spiele und Scenedemos konnten gleichzeitig im Background Musik und Gfx-Effekte ablaufen lassen. Nur der Begriff hieß halt Interrupts, unter DOS und x86-CPUs gibts bestimmt auch sowas. Wobei bei den x86-CPUs glaub ich ein Interrupt was anderes als auf dem C64 ist. 😉

    0
  • M

    gibts nicht genug multi-plattform GUI libraries?...

    0
  • ?

    Kann diese Argumentation was Plattformunabhängigkeit bzgl. GUI betrifft nicht nachvollziehen. Der Standard kann doch Schnittstelle und Semantik für eine GUI vorschreiben und der Code wäre letztlich wieder auf den gängigen Systemen verwendbar.

    Oder noch besser direkt zweigleisig fahren. D.h. einmal mit einer GUI, Socket, Thread, Boost und weiterem Luxus ausgestatteten Version mit der Zeit gehen und zum anderen einen abgespeckten Standard für eine Version im embedded Bereich anbieten.

    Die Zeiten ändern sich. Vielleicht sollte diese angestaubte, minimalistische C++ Philosopie es auch tun.

    0
  • R

    naaa? schrieb:

    Gibts in DOS Threads? hmmmmmm?

    Nicht nur, dass man es emulieren könnte. Aber der Punkt ist ja, dass man die Standard Library in zwei Teile aufteilen sollte, einmal einen "Erwarteten" und einmal einen "Optionalen".

    gibts nicht genug multi-plattform GUI libraries?...

    Aber mit keinem zufrieden stellenden Resultat, vorallem nicht im C++ Bereich. Außerdem wäre eine GUI Library zu umfangreich für den C++ Standard. Da könnte man wenn eher einen eigenen Standard für machen. Da gibt es ja von IEEE Motif als Standard. Aber das ist ja auch nicht mehr Zeitgemäß. Der GUI Bereich ist einfach zu unsicher und ändert sich extrem schnell.

    0
  • T

    Michael E. schrieb:

    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 😕

    Ja, denn ios::binary ist
    - nicht portabel (CPU- und OS-abhängig, z.t. gar nicht unterstützt)
    - nicht zwischen mehreren versionen des selben programms nutzbar, wenn sich zuviel ändert
    - nur schwer für tiefe objekt-hierarchien nutzbar
    - leider nicht in der lage irgendetwas anderes als char zu speichern

    und leichter zu komprimieren sind text-dateien auf jeden fall (wer lust und spaß dran hat 😛 )

    mfg

    0
  • O

    Ja, denn ios::binary ist
    - nicht portabel (CPU- und OS-abhängig, z.t. gar nicht unterstützt
    stimmt, portabel ist es nicht unbedingt
    - nicht zwischen mehreren versionen des selben programms nutzbar, wenn sich zuviel ändert
    und wieso? hatte in der hinsicht noch nie probleme
    - nur schwer für tiefe objekt-hierarchien nutzbar
    was haben denn objekte damit zu tun?
    - leider nicht in der lage irgendetwas anderes als char zu speichern
    unterscheidet sich damit aber auch nicht von den andren modi

    und leichter zu komprimieren sind text-dateien auf jeden fall (wer lust und spaß dran hat 😛 )
    halt ich fürn gerücht, da man bei binaries wohl genau die gleichen komprimierungsmethoden verwenden kann(mal davon abgesehen, dass man nicht aufpassen muss, dass man kein \0 reinschreibt...)

    0
  • M

    terraner schrieb:

    Ja, denn ios::binary ist
    - nicht portabel (CPU- und OS-abhängig, z.t. gar nicht unterstützt)
    - nicht zwischen mehreren versionen des selben programms nutzbar, wenn sich zuviel ändert
    - nur schwer für tiefe objekt-hierarchien nutzbar
    - leider nicht in der lage irgendetwas anderes als char zu speichern

    und leichter zu komprimieren sind text-dateien auf jeden fall (wer lust und spaß dran hat 😛 )

    Mal davon abgesehen, dass ich otzes Meinung hab, braucht man ios::binary wirklich. Wenn du es einfach wegwerfen willst, musst du auch für Ersatz sorgen.

    0
Anmelden zum Antworten