Der faule C++-Programmierer?



  • C- und C++-Programmierer sollen ja immer besonders faul sein - angeblich. Da wird i = i + 1 durch ++i, (*ptr).method() durch ptr->method() abgekürzt.

    Doch wie hält sich dieses Klischee in der heutigen Template-Zeit? Da sind die sogar bereit:

    std::vector<ns::class<typ> >::iterator iter = vec.begin();
    

    zu schreiben 😮

    Lange Rede kurzer Sinn, ist geplant in dieser Sprache endlich mal das Arbeiten mit Templates weniger '<' und weniger ':' zu verpassen? Wieso funktioniert immer noch kein:

    std:iterator iter = vec.begin();
    

    Warum lässt man Compiler immer noch nicht:

    int i = 5;
    vector vec;
    
    vec.push_back(i); // Aha <int> hätte er schreiben sollen
    

    erkennen?

    😞

    MfG SideWinder



  • SideWinder schrieb:

    Warum lässt man Compiler immer noch nicht:

    int i = 5;
    vector vec;
    
    vec.push_back(i); // Aha <int> hätte er schreiben sollen
    

    erkennen?

    Ich vermute, u.a., weil manche auch Werte in einen Vektor einfügen, die erst implizit gecastet werden müssen.
    Aber das scheint sowieso nicht so ernst gemeint gewesen zu sein 😉

    Moritz



  • #include <vector>
    
    typedef std::vector<int> ivec;
    typedef ivec::iterator   ivecit;
    
    int main()
    {
      ivec myvec;
      myvec.push_back(3);
      ivecit myit = myvec.begin();
    
      return *myit;
    }
    
    $ g++ -Wall --pedantic -o test test.cpp
    $ ./test
    $ echo $?
    3
    


  • Was spricht gegen eine abstrakte Basisklasse Iterator die für alle Typen funktioniert? Das Interface ändert sich ja nicht.

    MfG SideWinder



  • Du willst ja auch nicht immer casten wenn du den Wert hinter dem Iterator brauchst, oder?



  • Wegen der Typsicherheit.

    Bye, TGGC (Wähle deine Helden)



  • SideWinder schrieb:

    Warum lässt man Compiler immer noch nicht:

    int i = 5;
    vector vec;
    
    vec.push_back(i); // Aha <int> hätte er schreiben sollen
    

    erkennen?

    😞

    ein code sagt mehr als tausend worte:

    int i;
    std::cin>>i;
    
    vector vec;
    
    if(i==1){
        unsigned int a=5;
        vec.push_back(a);
    }
    if(i==2){
        math::vector3D b(3,2,1);
        vec.push_back(b);
    }
    

    was soll der compiler da machen? bedenke, dass c++ eine sprache mit einem statischen typsystem ist.

    und ein polymorpher iterator ist insofern schlecht, da man nicht weis, welchen typ er zurückgeben soll.

    aber vielleicht werden deine gebete ja in anderer form erhört:

    //typ von begin/end gleich dem rückgabetyp der methoden
    auto begin=vec.begin();
    auto end=vec.end();
    

    dieses feature würde soviel einfacher machen... 🙂



  • SideWinder schrieb:

    Doch wie hält sich dieses Klischee in der heutigen Template-Zeit? Da sind die sogar bereit:

    std::vector<ns::class<typ> >::iterator iter = vec.begin();
    

    zu schreiben 😮

    #define DEF(name,init) typeof(init) name(init)
    
    DEF(iter,vec.begin());
    


  • volkard schrieb:

    #define DEF(name,init) typeof(init) name(init)
    
    DEF(iter,vec.begin());
    

    Sobald typeof implementiert ist 🙂
    Außerdem wird das bei impliziter Wertumwandlung wieder ein Problem.



  • was ist eigentlich mit:

    vector<int>::iterator iter = vec.begin(); 
    iter = vec.erase(vec.begin() + 2);
    

    warum ist sowas böse und nicht standard? wie macht man es richtig?

    cu



  • SideWinder schrieb:

    Was spricht gegen eine abstrakte Basisklasse Iterator die für alle Typen funktioniert?

    TGGC schrieb:

    Wegen der Typsicherheit.

    Das ist ein guter Punkt. Wobei man noch weiter gehen kann. Da es in C++ keinen Typ gibt, zudem alle anderen Typen kompatibel sind (nein auch void* nicht), kann eine abstrakte Basisklasse gar nicht funktionieren. Was ginge wäre eine abstrakte Templatebasisklasse.
    Dagegen wiederum spricht die schlechte Performanz und das erschwerte Memory-Management, denn:
    1. Wäre jede Operation damit eine virtuelle.
    2. Könnten Zeiger dann nicht mehr so ohne weiteres Iteratoren sein (ein Zeiger kann keine Basisklasse haben).
    3. Wären Iteratoren dann in der Regel Heap-Objekte.

    Der neue Standard wird das auto-Keyword so umdefinieren, dass du dann sowas schreiben kannst:

    std::vector<int> vec;
    auto it = vec.begin();
    

    mark1 schrieb:

    was ist eigentlich mit:

    vector<int>::iterator iter = vec.begin(); 
    iter = vec.erase(vec.begin() + 2);
    

    warum ist sowas böse und nicht standard?

    Das ist weder böse noch nicht standard.



  • C- und C++-Programmierer sollen ja immer besonders faul sein - angeblich. Da wird i = i + 1 durch ++i, (*ptr).method() durch ptr->method() abgekürzt.

    Das ist grober Unfug von BASIC-Programmierern.



  • wieso denn ausgerechnet von basic? bei object pascal funktioniert sowas à la i++ auch nicht. und ob jemand abkürzt oder nicht, ist meiner meinung nach 'ne stilfrage.



  • Es geht um viel mehr.
    Man schreibt && statt AND, "if (...)" statt "IF ... THEN", ... . Alles immer ein paar Zeichen kürzer, dafür kryptischer. Deswgen sieht es auf den ersten Blick so aus, als wäre C-Code besonders darauf aus kurz zu sein. Sowas höhrt man öfters, wenn Basic-Programmierer über C und dessen abkömmlinge lästern. Mag sein, das das auch auf Pascal-Programmierer zutrifft.

    Wenn man sich dann aber allein schon Python anguckt stellt man schnell fest, das vieles noch deutlich kürzer geht und trotzdem nicht kryptisch sein muss.

    C++-Programmierer nehmen verdammt viel in kauf. Auto ist zwar mit Sicherheit eine sehr vernümpftige Sache (die andere Sprachen schon seit 30 Jahren haben), wird aber vermutlich nciht dafür sorgen, dass diese vorurteile verschwinden.

    C++ ist einfach irgendwie total vermurkst.



  • Helium schrieb:

    C++ ist einfach irgendwie total vermurkst.

    Und viele Leute verwenden es trotzdem gerne. So what? 🙂



  • Helium schrieb:

    C++-Programmierer nehmen verdammt viel in kauf. Auto ist zwar mit Sicherheit eine sehr vernümpftige Sache (die andere Sprachen schon seit 30 Jahren haben), wird aber vermutlich nciht dafür sorgen, dass diese vorurteile verschwinden.

    C++ ist einfach irgendwie total vermurkst.

    Etwas krasse Ansicht. Aber du mußt C++ ja nicht benutzen.

    Helium schrieb:

    C- und C++-Programmierer sollen ja immer besonders faul sein - angeblich. Da wird i = i + 1 durch ++i, (*ptr).method() durch ptr->method() abgekürzt.

    Das ist grober Unfug von BASIC-Programmierern.

    "Sogar" in BASIC gibt es zuweilen sowas:

    INC i
    

    Moritz



  • Walli schrieb:

    Helium schrieb:

    C++ ist einfach irgendwie total vermurkst.

    Und viele Leute verwenden es trotzdem gerne. So what? 🙂

    Viele Leute hören sich gerne Dieter Bohlen an. So what?

    audacia schrieb:

    Helium schrieb:

    C++-Programmierer nehmen verdammt viel in kauf. Auto ist zwar mit Sicherheit eine sehr vernümpftige Sache (die andere Sprachen schon seit 30 Jahren haben), wird aber vermutlich nciht dafür sorgen, dass diese vorurteile verschwinden.

    C++ ist einfach irgendwie total vermurkst.

    Etwas krasse Ansicht. Aber du mußt C++ ja nicht benutzen.

    Muss ich nicht? Ach. Und wie kommst du darauf? Natürlich hat man da völlig freie Wahl und ist überhaupt nicht durch irgendwelche äußeren Faktoren gebunden.

    Helium schrieb:

    C- und C++-Programmierer sollen ja immer besonders faul sein - angeblich. Da wird i = i + 1 durch ++i, (*ptr).method() durch ptr->method() abgekürzt.

    Das ist grober Unfug von BASIC-Programmierern.

    "Sogar" in BASIC gibt es zuweilen sowas:

    INC i
    

    Ja, oder man kann sich so etwas selbstschreiben:

    SUB INC (BYREF x AS INTEGER)
       x = x + 1
    END SUB
    

    Einfach unglaublich. Das ändert aber nichts daran, das C für die meisten Basic-Programmierer kryptisch aussieht, oder etwa doch?

    -----------------------------

    C++ hat vielleicht eines der mächtigsten Template-Systeme überhaupt, aber im täglichen Leben besteht der meiste Code den ich schreibe nicht aus den abgefahrensten TMP-Tricks, sondern aus ganz anderen Dingen und in den Bereichen ist C++ dann verdammt schwach, wie die meisten Mainstream-Sprachen.



  • Helium schrieb:

    audacia schrieb:

    Aber du mußt C++ ja nicht benutzen.

    Muss ich nicht? Ach. Und wie kommst du darauf? Natürlich hat man da völlig freie Wahl und ist überhaupt nicht durch irgendwelche äußeren Faktoren gebunden.

    OK, das ist was anderes.

    Helium schrieb:

    audacia schrieb:

    "Sogar" in BASIC gibt es zuweilen sowas:

    INC i
    

    Ja, oder man kann sich so etwas selbstschreiben:

    SUB INC (BYREF x AS INTEGER)
       x = x + 1
    END SUB
    

    Einfach unglaublich. Das ändert aber nichts daran, das C für die meisten Basic-Programmierer kryptisch aussieht, oder etwa doch?

    Das speziell nicht.
    Trotzdem: ich bin bis heute aktiver BASIC-Programmierer. Mit BASIC habe ich zu programmieren angefangen und später noch C++ gelernt, und ich hatte nie Probleme mit den syntaktischen Unterschieden dieser Sprachen. Beide Sprachen haben ihre Vorteile. Das für viele ein Vorurteil über BASIC darstellende "i=i+1" ist meist ein Anfängerfehler, der in C(++) genauso häufig vorkommt.

    Helium schrieb:

    C++ hat vielleicht eines der mächtigsten Template-Systeme überhaupt, aber im täglichen Leben besteht der meiste Code den ich schreibe nicht aus den abgefahrensten TMP-Tricks, sondern aus ganz anderen Dingen

    ACK.

    Helium schrieb:

    und in den Bereichen ist C++ dann verdammt schwach, wie die meisten Mainstream-Sprachen.

    No ACK.

    Moritz



  • <sarkasmus>Warum schreiben wir nicht alle COBOL, wenns nur um Lesbarkeit geht?</sarkasmus>


Anmelden zum Antworten