3. C++ 0x

C++ 0x

  • ?

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

    kingruedi schrieb:

    Aber der Punkt ist ja, dass man die Standard Library in zwei Teile aufteilen sollte, einmal einen "Erwarteten" und einmal einen "Optionalen".

    Ich weiß nicht. Genau in dem Moment reicht dann dein standardkonformer Code schon wieder nicht aus und du brauchst nen gutmütigen Compiler. Dieser gutmütige Compiler hat dann für Win und Mac OS und Solaris (weil er von Sun ist 😉 ) die Implementierung und für Linux nicht.

    Nene, dieses Minimum an stdlib ist IMHO einfach nicht mehr das, was die Leute wollen. Ich will keinen eigenen URL-Encoder schreiben, der aus "Hoi Alter ?" "Hoi+Alter%22" macht und ich will auch nicht danach suchen und ich will auch keine Sockets erst suchen und erst die dritte gefundene lib mögen, etc. Ich denke aber auch, dass sich C++ in dieser Hinsicht nicht mehr prinzipiell ändern wird und sehe deshalb die Zukunft der Sprache für die Anwendungsentwicklung als gefährdet.
    Es gibt außerdem noch so viele feine Sachen, die man in pure C++ schreiben könnte, ohne dass die Compilerbauer mehr Aufwand hätten, wie z.B. ne Klasse für große Zahlen, nen URL-Encoder, anständige Collections, ... und sowas liegt der stdlib einfach nicht bei. Das verstehe ich nicht.

    0
  • R

    terraner schrieb:

    Ja, denn ios::binary ist
    - nicht portabel (CPU- und OS-abhängig, z.t. gar nicht unterstützt)

    Unterstützt wird es immer, nur bringt es auf Betriebssystemen, für die Text- und Binärmodus gleich ist keinen unterschied. Aber trotzdem kein Grund das nicht einzubinden, da ein populäres OS noch diese Unterscheidung hat.

    - nicht zwischen mehreren versionen des selben programms nutzbar, wenn sich zuviel ändert

    😕 was du meinst ist was anderes, aber das hat nichts mit ios::binary zu tun

    - nur schwer für tiefe objekt-hierarchien nutzbar

    😕

    - leider nicht in der lage irgendetwas anderes als char zu speichern

    äh 😕

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

    äh? Die Zahl 0xFFFF nimmt Binär nur 2 Byte ein, im Textmodus 4 bzw. 6 mit führendem 0x...

    Tut mir leid, dass ich dir das sagen muss, aber es Hört sich an, als hättest du nicht so viel Ahnung davon.

    @Optimizer
    Ein URL-Encoder ist vielleicht zu konkret, da er ja ein bestimmtes Protokoll/Format umsetzt. Aber allgemeinere Dinge fehlen definitiv. Die Klasse für große Zahlen hast du ja bereits angesprochen. Solche Dinge werden ja auch in C++0x aufgenommen.

    0
  • T

    kingruedi schrieb:

    Tut mir leid, dass ich dir das sagen muss, aber es Hört sich an, als hättest du nicht so viel Ahnung davon.

    da es nicht portabel ist und ich auf zwei systemen programmiere, benutze ich es nicht. es ist schon wahr das ich nicht viel ahnung von ios::binary habe. ich bin vor einiger zeit auf einen artikel gestoßen, indem das so ähnlich drinstand. und deshalb habe ich mich jetzt an dem artikel orientiert.
    sry, wenn es falsch ist.

    mfg

    0
  • ?

    bis das rauskommt proggt eh die halbe Welt in Java und .NET 😃

    0
  • S

    lalalala schrieb:

    bis das rauskommt proggt eh die halbe Welt in Java und .NET 😃

    Muss auch sagen, dass die zeitliche Planung imho etwas, hmm naja, erschreckend ist 🙄

    Wenn da dann keine Sockets und Threads reinkommen, werde ich jeden verstehen, der über C++ lacht. Aber erst dann 🙂

    0
Anmelden zum Antworten