Infos über neuen C++-Standard? Thread Nr.2



  • Ich glaub GTKmm ist da schon auf dem richtigen Weg.

    unter http://gtkmm.sourceforge.net/features.shtml
    Cross-platform: Linux, Solaris, Win32, others
    aber für win32 finde ich da nix 😞



  • [OT]Ich lese jetzt schon lange sehr interessiert mit, ich finde die zwei Threads sollten ins Archiv der besonders interessanten Diskussionen![/OT]



  • Original erstellt von Lars:
    irgendwie nutzen die ganzen GUI Libs net mal das Prinzip der Iteratoren. Dabei ist das genial.

    Ich halte die Umsetzung von Iteratoren in C++ (der 'STL') nicht gelungen. Iteratoren haben dort zu viele (2) Aufgaben: Das Navigieren durch Container und das Auslesen/Setzten von Werten.

    <ot>Edit: 1000 Postings! *freu* :)</ot>

    [ Dieser Beitrag wurde am 17.01.2003 um 21:27 Uhr von Daniel E. editiert. ]



  • Original erstellt von kingruedi:
    Deswegen würde ich Backends in C++ schreiben und die GUI mit irgend etwas portablen draufpacken, wie Java oder Python und was es da alles gibt, hauptsache man hat schnell eine GUI zusammen geklickt und kann halbwegs sein Backend ansteuern.

    jo!
    wenn man erstmal 3 sprachen (der algol-gruppe) kann, dan kosten einen die nächsten 6 sprachen (der algol-gruppe) jeweils ein langes wochenende.

    und es ist saugeil, zu jeder anwendung eine geignete sprache zu nehmen. gerade hab ein perl-script laufen, das ne dos-batch laufen läßt, die zwei c-pogs, ein c++-prog, und dann wieder ein c-prog laufen läßt. das perl-script überwacht, ob änderungen der dateidaten da waren. wenn ja, wird einfach alles neu compiliert und ausgeführt und ich krieg die ausgabe. ähnlich locker gehe ich mit java und c# um. ich werde diese sprachen niemals lieben, wie ich mal c++ liebte, aber als werkzeug stets benutzen, wenn sie sich anbieten.
    und mit der großen diskrepanz zwischen "ich mag c++ benutzen, weil es die einzige sprache ist, die mir erlaubt, echt OO zu schreiben" und "ich hasse c++, weil ich nichtmal nen cursor bewegen kann und alle großen libs zum kotzen sind" muß man offen für weitere sprachen sein.



  • Original erstellt von Daniel E.:
    **Ich halte die Umsetzung von Iteratoren in C++ (der 'STL') nicht gelungen. Iteratoren haben dort zu viele (2) Aufgaben: Das Navigieren durch Container und das Auslesen/Setzten von Werten.

    <ot>Edit: 1000 Postings! *freu* :)</ot>

    [ Dieser Beitrag wurde am 17.01.2003 um 21:27 Uhr von [qb]Daniel E.** editiert. ][/QB]

    und warum lassen die sich nicht vereinen? Wie würdest du deine listenklasse implementieren?



  • Original erstellt von Lars:
    [QB]und warum lassen die sich nicht vereinen?[qb]

    Weil sie nicht das gleiche machen ...?

    Die Konzepte können/sollen miteinander interagieren, aber sie sollen nicht identisch sein. Sie tun schließlich nicht das Gleiche.
    [Und man sollte zwischen Lese- und Schreibzugriffen explizit unterscheiden können - dann geht gleich der Mist mit const_iterator, iterator usw. über Bord. Iteratoren liefern beim 'dereferenzieren' eben eine eindeutige 'Kennung des Objekts', mit dem der Iterator 'verknüpft' ist. Diese Kennung kann im einfachsten Fall eine Referenz sein.]



  • Also übers typeof sind wir uns dann ja inzwischen einig.

    Was mich aber eigentlich besonders stört am std::for_each ist noch nicht mal, dass man die Schleife in eine extra funktion auslagern muss (meine Schleifen sind normalerweise eh größer als eine Zeile), sondern dass man ja noch nicht mal jede Funktion aufrufen kann! Bei Methoden muss man mit nem Funktionsadapter rumtun, und die Binder sind ja wohl die allerletzte Krücke und wenn man mehr als zwei Parameter hat, müsste man auch noch anfangen selber das Teil zu basteln...

    Deswegen möcht ich noch ein neues Schlüsselwort einwerfen 😉
    Beim CBuilder gibts das __closure. Damit kann man Memberfunktionen wie normale behandeln

    void __closure(*DoSomething)(int);

    is ein Funktionszeiger für jede Methode, die ein int bekommt. Man spart sich das ganze mem_fun und mem_fun_ref getue (und regelmäßige im Forum gestellte Fragen).

    Ach ja*

    The ISO C++ standard is now about two and a half years
    old. In about another two and a half years it could be
    revised, amended, or - of course - left alone.*

    hm, wann wurde der Standard verabschiedet? 97? Welches Jahr haben wir jetzt?

    aus http://www.research.att.com/~bs/kbh-C++0x.pdf

    [ Dieser Beitrag wurde am 18.01.2003 um 05:18 Uhr von kartoffelsack editiert. ]



  • 97 veröffentlicht und 98 festgelegt.

    @Dimah
    http://cvs.gnome.org/lxr/source/gtkmm-root/base/README.win32

    ist wahrscheinlich ein bissel kompliziert, da GTKmm ein Wrapper eines Wrappers ist 😉

    @volkard

    wenn man erstmal 3 sprachen (der algol-gruppe) kann, dan kosten einen die nächsten 6 sprachen (der algol-gruppe) jeweils ein langes wochenende.

    bei dir bin ich mir manchmal nicht sicher, ob du gerade ironisch bist oder das wirklich ernst meinst 😉

    @kartoffelsack

    void __closure(*DoSomething)(int);

    is ein Funktionszeiger für jede Methode, die ein int bekommt.

    Ich verstehe nicht ganz wie das funktionieren soll, hast du vielleicht ein Beispiel dafür?

    @DanielE.

    <ot>Edit: 1000 Postings! *freu* :)</ot>

    herzlichen Glückwunsch 🙂



  • Original erstellt von kingruedi:
    [QB]@volkard
    wenn man erstmal 3 sprachen (der algol-gruppe) kann, dan kosten einen die nächsten 6 sprachen (der algol-gruppe) jeweils ein langes wochenende.
    bei dir bin ich mir manchmal nicht sicher, ob du gerade ironisch bist oder das wirklich ernst meinst[QB]

    Wohl kaum ironisch.

    Etwas ähnliches hat mal ein Dozent bei uns gesagt: lernen Sie eine Programmiersprache gründlich. Wenn Sie dann mal jemand freitags fragt, ob Sie montags ein Programm in einer Sprache programmieren können, dann sagen Sie ruhig ja.



  • Naja das hörte sich ein wenig übertrieben an.



  • Original erstellt von kingruedi:
    **@Dimah
    http://cvs.gnome.org/lxr/source/gtkmm-root/base/README.win32

    ist wahrscheinlich ein bissel kompliziert, da GTKmm ein Wrapper eines Wrappers ist 😉
    **

    kenne ich schon, bissel kompliziert ist gut



  • Original erstellt von Marc++us:
    **
    Etwas ähnliches hat mal ein Dozent bei uns gesagt: lernen Sie eine Programmiersprache gründlich. Wenn Sie dann mal jemand freitags fragt, ob Sie montags ein Programm in einer Sprache programmieren können, dann sagen Sie ruhig ja.**

    Das einzige was dabei nervt sind die fehlenden Vokabeln der Sprache....



  • Marc++us:

    Typische Embedded-C++-Dialekte lassen ohnehin gleich die Masse der Stdlib weg, und in der Sprache sterben als erstes die Templates. Da gibt's sogar einen Industriestandard zu Embedded-C++, ohne Templates, demnach ohne STL. Da blutet dem ISOisten doch das Herz.

    http://www.research.att.com/~bs/bs_faq.html#EC++



  • was ich mir noch wünche ist das nan die grösse eines dynamischen arrays rausbekommen kann, die grösse wird ja jetzt schon irgend wo gespeicher (wie sonst könnte delete[] arbeiten)

    und immer die ausrede, ne das können wir nicht weil ein toster das nich so gut kann



  • was ich mir noch wünche ist das nan die grösse eines dynamischen arrays rausbekommen kann

    Und wozu soll das gut sein? Erstens habe ich die größe sowieso, da ich sie ja angeben muss. Und zweitens gibt's da ja auch noch sowas schönes wie Container.

    Außerdem müsste der C++ Standard sich dazu in die technische Details der Implementation einmischen.



  • Original erstellt von HumeSikkins:
    Und wozu soll das gut sein? Erstens habe ich die größe sowieso, da ich sie ja angeben muss. Und zweitens gibt's da ja auch noch sowas schönes wie Container.

    aber die grösse verlierst du schnell wenn du das array an eine funktion übergibst,
    container machen ihre arbeit gut, aber was ist dagen zu sagen sich eine möglichkeit offen zu halten

    außerdem tut es mir weh, jedesmal wenn ein newbie kommt und fragt wie man die grösse eines dynamischen arrays bekommt und ich muss ihn sagen das er es extra speicher muss,
    z.b. java oder c# können das auch, ok sie haben ein gc und bei denen ist es nicht so gefährlich mir dynamischen arrays zu arbeiten, aber verspert uns der standard möglichkeiten damit neulinge zu container gezwungen werden?

    Original erstellt von HumeSikkins:
    Außerdem müsste der C++ Standard sich dazu in die technische Details der Implementation einmischen.

    bei delete[] haben die aber schon, wenn nicht hätten wir jetzt ein delete[size_t n]



  • Und gib mal ein Beispiel, wie du das implementieren würdest, dimah



  • ich würde nix implementieren ich würde nur schon vorhanden information zugänglich machen
    mir tut einfach die redundanz weh, entweder ein delete[size_t n] oder ein array_size()



  • ok, dann anders rum: wie ist das im moment implementiert (ein beispiel einer Implementation)?
    ok, bin schon müde, also in der nacht nicht mehr nötig! Cu!



  • void * operator new[](size_t n)
    {
        void * speicher = ::operator new( n + sizeof( size_t ) );
        static_cast<size_t *>( speicher )[0] = n;
        return &static_cast<size_t *>( speicher )[1];
    }
    
    void operator delete[](void * speicher)
    {
        ::operator delete( &static_cast<size_t *>( speicher )[-1], static_cast<size_t *>( speicher )[-1] );
    }
    
    size_t sizeofarray(void * array)
    {
        return static_cast<size_t *>( array )[-1];
    }
    

    bin mir aber nicht sicher ob ich das mit new und delete richtig gemacht habe


Anmelden zum Antworten