Soll die neue Funktionsdeklaration in C++0x die Alte vollständig ersetzen?



  • also ich finde die alte
    also

    int a = 5;
    

    viel besser als irgendwie

    auto x = 5;
    

    sieht man auf einen blick wozu das dingen da ist und wie man damit umgeht

    das ist in php meines wissens auch so und ich fidne es eifnach nur unübersichtlich...


  • Administrator

    @Skym0sh0,
    Darum geht es ja auch nicht, ich denke man wird dort weiterhin folgendes schreiben:

    int a = 5;
    

    Das auto wurde ja eher für das folgende eingeführt:

    auto first_function() -> int;
    auto second_function() -> double;
    // usw.
    
    template<typename T>
    void template_function(T Function)
    {
        auto Value = Function();
    
        // Mache was mit Value.
    }
    
    // irgendwo:
    template_function(&first_function);
    template_function(&second_function);
    

    Grüssli



  • Skym0sh0 schrieb:

    also ich finde die alte
    also

    int a = 5;
    

    viel besser als irgendwie

    auto x = 5;
    

    sieht man auf einen blick wozu das dingen da ist und wie man damit umgeht

    Ach, und bei 5 siehst Du nicht auf den ersten Blick, dass das ein int ist? Dann liegt das Problem aber woanders …

    das ist in php meines wissens auch so und ich fidne es eifnach nur unübersichtlich...

    Das hat hier nichts mit PHP zu tun … PHP ist dynamisch typisiert. C++ weiterhin statisch.

    @OP: Ach so, Funktions~. Was meinst Du dann damit? Was hat sich dort geändert?



  • Konrad Rudolph schrieb:

    @OP: Ach so, Funktions~. Was meinst Du dann damit? Was hat sich dort geändert?

    [] foo(int) -> int

    und nochmal kurz zu auto:
    was wir brauchen ist mehr auto - type inference wie zB aus ocaml ist einfach nur enorm praktisch. also ich werde auto lieben 🙂



  • hat auto nicht die entgegengesetzte bedeutung zu static? Wird jetzt das alte auto einfach so rausgeworfen? OK es war sowiso überflüssing, weil es sowiso immer glat wenn man nicht static dran geschrieben hat.



  • hat auto nicht die entgegengesetzte bedeutung zu static? Wird jetzt das alte auto einfach so rausgeworfen? OK es war sowiso überflüssing, weil es sowiso immer glat wenn man nicht static dran geschrieben hat. Aber irgendwie erinnert es mich ein wenig an B



  • Ist ja schön und gut wenn sich hier eine Diskussion über Sinn und Unsinn von auto entwickelt, aber meine Frage hätte ich trotzdem gerne beantwortet.



  • Die Frage lässt sich ganz eindeutig mit "Nein" beantworten. HTH



  • Shade Of Mine schrieb:

    Konrad Rudolph schrieb:

    @OP: Ach so, Funktions~. Was meinst Du dann damit? Was hat sich dort geändert?

    [] foo(int) -> int

    Sorry wenn ich das jetzt nicht ganz verstehe, aber was wird sich nun konkret an der Funktionsdeklaration verändern? Kann das jemand an einem guten Beispiel erläutern?



  • Es wird sich nichts verändern, es wird aber was dazukommen. Dazu liest du am besten diesen Artikel:
    http://www.c-plusplus.net/forum/viewtopic-var-t-is-204654.html
    (Abschnitt 1.5)

    Das was Shade da fabriziert hat ist übrigens ein Lambda-Ausdruck, das ist nicht dasselbe wie eine Funktionsdeklaration.



  • Ich habe den Artikel bereits gelesen, allerdings habe ich mit der Frage auch mehr die Absicht gemeint, es ist klar, dass die alte Funktionsdeklaration erhalten bleibt, aber gibt es irgend einen Grund diese noch zu verwenden, oder ist es ein weiteres veraltetes Ding wie C-Style Casts u.s.w.?



  • auto in seiner alten form wird es nicht mehr geben, aber ich habe es tatsächlich auch nie verwendet oder in verwendung gesehen.
    und es wurde tatsächlich (auch) aus dem grund eingeführt, die neue funktionsdeklaration zu ermöglichen:

    auto fun () -> int
    {
      return 42;
    }
    

    ich glaube nicht, dass das jemand so verwenden wird, denn int fun () ist um einiges kürzer zu schreiben.

    bei manchen rückgabetypen wird es jedoch sicher einfacher sein, die neue funktionsdeklaration zu verwenden, z.b. bei komplexen rückgabetypen (tuples, funktionszeiger) - und mit der neuen funktionsdeklaration ist überaus einfacher, funktionszeiger zu deklarieren (und sehr viel schöner, funktionszeiger auf funktionen, die funktionen zurückgeben zu deklarieren).

    dann gibt es noch ein einsatzgebiet, wo du die neue funktionsdeklaration verwenden *musst*:

    template <Arithmetic A>
    auto twice (A&& a) -> decltype(A + A)
    {
      return a + a;
    }
    

    dieses beispiel ist aber auch im artikel erwähnt.

    /edit: wenn user-defined literals noch in den standard reinkommen (ich zweifle), dann würde wahrscheinlich auto noch besser genutzt werden können:

    auto str = "foo"s;
    
    //decltype(str) == decltype(std::string)
    


  • Bashar schrieb:

    Es wird sich nichts verändern, es wird aber was dazukommen. Dazu liest du am besten diesen Artikel:
    http://www.c-plusplus.net/forum/viewtopic-var-t-is-204654.html
    (Abschnitt 1.5)

    Das was Shade da fabriziert hat ist übrigens ein Lambda-Ausdruck, das ist nicht dasselbe wie eine Funktionsdeklaration.

    was mich nur wundert, und was wahrscheinlich auch der grund war weshalb shade diese syntax gepostet hat ist, dass die englische wikipedia die auto syntax nichtmehr enthält:

    http://en.wikipedia.org/wiki/C%2B%2B0x#Unified_function_syntax

    aus dem Artikel:

    struct SomeStruct
    {
      []FuncName(int x, int y) -> int;
    }
    
    []SomeStruct::FuncName(int x, int y) -> int
    {
      return x + y;
    }
    


  • Bashar schrieb:

    Das was Shade da fabriziert hat ist übrigens ein Lambda-Ausdruck, das ist nicht dasselbe wie eine Funktionsdeklaration.

    ah, ja sorry.
    auto war es hier ja.

    hab mich lediglich auf das -> type
    am ende konzentriert 😕



  • queer_boy schrieb:

    bei manchen rückgabetypen wird es jedoch sicher einfacher sein, die neue funktionsdeklaration zu verwenden, z.b. bei komplexen rückgabetypen (tuples, funktionszeiger)

    *g* davon kann ich ein Lied singen:

    template <typename TChar, typename TSpec, typename TPos>
    inline typename Iterator<typename Host<StringSet<TChar, Packed<TSpec> > >::Type>::Type
    hostIter(StringSet<TChar, Packed<TSpec> > const& strs, TPos pos) {
        return begin(host(strs[pos]));
    }
    

    Da ist 'auto' natürlich praktisch.

    dann gibt es noch ein einsatzgebiet, wo du die neue funktionsdeklaration verwenden *musst*:

    template <Arithmetic A>
    auto twice (A&& a) -> decltype(A + A)
    {
      return a + a;
    }
    

    Müsste es hier nicht 'decltype(a + a)' heißen?



  • Konrad Rudolph schrieb:

    queer_boy schrieb:

    bei manchen rückgabetypen wird es jedoch sicher einfacher sein, die neue funktionsdeklaration zu verwenden, z.b. bei komplexen rückgabetypen (tuples, funktionszeiger)

    *g* davon kann ich ein Lied singen:

    template <typename TChar, typename TSpec, typename TPos>
    inline typename Iterator<typename Host<StringSet<TChar, Packed<TSpec> > >::Type>::Type
    hostIter(StringSet<TChar, Packed<TSpec> > const& strs, TPos pos) {
        return begin(host(strs[pos]));
    }
    

    ...

    😃 👍

    Allerdings habe ich mir derzeit schon einen "Skip-Blick" angewöhnt:

    • Erstmal die '(' suchen,
    • dann den Bezeichner davor - dann weiß man schonmal, wie die Funktion heißt und vermutlich machen soll (oder ob der A*** einen FunkPtr zurückgeben will 😉 )
    • und von da aus nach rechts die Parameter ...
    • und nach links den Rückgabetypen.

    Das Vorgehen werde ich nun ein wenig modifizieren müssen.
    Ich bin auf jeden Fall schon gespannt, wie/wo sich die "->-Schreibweise" durchsetzen wird ... nur da, wo das andere zu kompliziert ist ... oder evtl. auf breiterer Basis.

    Gruß,

    Simon2.



  • Shade Of Mine schrieb:

    Bashar schrieb:

    Das was Shade da fabriziert hat ist übrigens ein Lambda-Ausdruck, das ist nicht dasselbe wie eine Funktionsdeklaration.

    ah, ja sorry.
    auto war es hier ja.

    Naja, wenn die Wiki-Seite stimmt und ich sie auf die Schnelle richtig verstanden habe, wird man wohl Funktionen auch als benannte Lambda-Ausdrücke (ist das nicht irgendwo ein Widerspruch? 🙂 ) definieren können.



  • Nunja, aber wenn die alte leglich kürzer zu schreiben ist, man die neue aber dennoch manchmal braucht, fände ich es wesentlich konsistenter durchgängig die neue zu verwenden, oder etwa nicht?



  • JustAnotherNoob schrieb:

    Nunja, aber wenn die alte leglich kürzer zu schreiben ist, man die neue aber dennoch manchmal braucht, fände ich es wesentlich konsistenter durchgängig die neue zu verwenden, oder etwa nicht?

    Ich seh das mit dem "auto" als zweischneidiges Schwert. Sicher hilft es bei komplexen Ausdrücken ungemein (Und dafür würde ich es auch verwenden), aber bei einfachen Ausdrücken (Sprich sowas wie std::string, int...) ist mir es lieber wenn ich den Typ auf einen Blick erfassen kann.

    Den wie heiß es so schön:

    Man liest Code häufiger, als man ihn schreibt.

    So werde ich wohl auch in Zukunft dann vorgehen: Für einfache Ausdrücke die alte Schreibweise verwenden, für komplexe siegt imho die Kürze über den Informationsgehalt, da man bei solchen Ausdrücken eh letzteres nicht gegeben ist (Komplexe Ausdrücke sind meist sowieso nicht mit einen Blick zu erfassen).

    cu André



  • Bashar schrieb:

    Naja, wenn die Wiki-Seite stimmt und ich sie auf die Schnelle richtig verstanden habe, wird man wohl Funktionen auch als benannte Lambda-Ausdrücke (ist das nicht irgendwo ein Widerspruch? 🙂 ) definieren können.

    als ich letztens meinen artikel auf die neue lambda-schreibweise upgedatet habe, bin ich tatsächlich auf ein solches proposal gestoßen. ich weiß zwar nicht mehr genau warum, aber damals dachte ich mir, dass das wohl nicht durchkommt (zu unausgereift vielleicht, und außerdem könnte der neue standard ja jetzt seit samstag schon feature complete sein, und wenn das ein neues proposal war...)

    aber da müsste ich jetzt nochmal durch die proposal schauen, was mir im moment etwas zu mühsam ist. lieber den neuen draft abwarten.


Anmelden zum Antworten