warum taucht er hier die werte nicht



  • itman schrieb:

    Referenzen sind meistens schlecht weil sie verbergen dass Funktion Werten wechseln kann.

    Das ist ein mittlerweile veraltetes Dogma.



  • itman schrieb:

    Und wenn Man diese Funktion zum ersten Mal sieht weiss es nicht dass Sie argumenten modifizirt 🙂

    Tja, dann musst du die Lib wechseln. 33 Parameter ist abnormal :p

    Gib mal ein Beispiel einer Funktion die einen Wert ändert wo das nicht klar ist.

    Betrachte dir zB mal std::swap - da sind es auch Referenzen.

    Mit Standardfunktionen ist es nicht so schlect. Standardfunktionen muss Man beinahe auswending weissen 🙂

    Warum?
    Also ich kenne zwar viele Funktionen der Standardbibliothek, aber bei weitem nicht alle. Und zB von boost kenne ich nur recht wenige...

    Eine Funktion muss intuitiv sein - und swap() ist das. Mit Zeigern wäre es möglich, aber wir haben mittlerweile C++ - da sind die Zeiger unnötig.

    Zeig mir doch mal eben eine gute Library wo out Parameter immer Zeiger sind.
    Das macht nur dann Sinn, wenn der Param auch 0 sein kann - sonst bin ich mit Referenzen einfach besser dran.



  • Das sind aber religiöse Kriege 🙂



  • itman schrieb:

    Das sind aber religiöse Kriege 🙂

    Wieso?
    Ich wüsste jetzt keine Library die deinen Weg geht - insofern ist es wohl kein religiöser Krieg, sondern da tanzt nur jemand aus der Reihe...



  • Shade Of Mine schrieb:

    Ich wüsste jetzt keine Library die deinen Weg geht - insofern ist es wohl kein religiöser Krieg, sondern da tanzt nur jemand aus der Reihe...

    ich weiß ja nicht, wo du c++ gelernt hast, aber bei mir war es nicht.
    wäre es bei mir gewesen, wüßtest du, daß zeiger out-parameter bedeuten sollten.
    referenzen fühlen sich wie call by value aus und sollten deshalb auch gleich so behandelt werden.
    daß swap üblicherweise mit referenzen angeboten wird, ist eine historische fehlleistung und nicht wiedergutzumachen.
    ich schreib in http://www.volkard.de/vcppkold/call_by_reference.html "Leider sieht man diese swap-Funktion sehr häufig. Bitte vermeiden Sie diese Verwendung von Referenz-Parametern trotzdem! Daß die Variablen a und b in der main-Funktion verändert werden können, nur weil sie Argumente einer Funktion waren ist einfach zu fehlerträchtig."
    wir können ja mal drüber diskutieren, ob die debugzeit nun das zehnfache der eintippzeit beträgt oder mehr oder weniger. und ob es wichtig ist, leicht zu debuggenden code zu basteln. und ob das debugging immer so vonstatten geht, daß man variableninhalte inspiziert und bei nem fehlerhaften inhalt guckt, wo das passiert sein kann. und ob man bei ner fehlerhaften variablen b und vielen aufrufen der art f(a,b,c,d); nicht scheinemäßig häppy wäre, wenn man sich auf seinen stil verlassen könnte, und genau wüßte: da wurde b nicht zerkloppt, ich kann woander gucken.
    also bei mir kann nur a=f(x,y,z) oder f(a,&b,c,d) dran schuld gewesen sein. und irgendwie hab ich keine angst vor nullen. kann mich nicht daran erinnern, vor dem problem gestanden zu haben, nicht zu wissen, ob ne funktion 0 essen kann, oder nicht.
    hab zwar keine ahnung, ob strlen(0) klappt, aber ich rufe sowas nie auf. falls der strung ==0 wäre, dann wärs ja ein eingabefehler gewsen, den ich dort schon gefangen hätte.



  • Und genau das ist einer der wenigen Punkte wo ich mit dir nicht übereinstimme.

    Ausser von dir habe ich das Zeiger == out Parameter noch nicht gehört.

    Bei strlen() ist der Zeiger auch kein out Parameter, sondern einfach nötig - der der Typ 'char*' verarbeitet wird und nicht ein Zeiger auf char.

    Mein VC++ zeigt mir schön die Typen der Parameter an - insofern weiss ich automatisch: type& ist ein out Parameter, wobei ich mir bei type* nicht sicher sein kann. Schließlich muss Zeiger nicht gleich out Parameter heissen, da man Zeiger auch schön verwenden kann um einen 0 Wert zu haben, während type& nur bei out Parametern Sinn macht.

    Für mich ist ein out Parameter durch type& gekennzeichnet - das ist direkt im Code natürlich nicht so ersichtlich, aber ist es mit Zeiger wirklich denn besser?

    Mir fällt kein Beispiel ein, wo es mit einem & klar ist, dass es ein out Parameter ist 😞 Vielleicht kannst du ja ein konkretes Beispiel bringen.

    Wenn man #define & out schreibt und dann immer:

    split(str, '\n', out vec);
    

    Wäre es vielleicht besser.

    Aber um ehrlich zu sein: ein
    cin>>&i; bzw. cin>>out i;
    würde mich sehr abschrecken...

    Insofern kann man das wohl nicht konsequent durchziehen...



  • Shade Of Mine schrieb:

    itman schrieb:

    Das sind aber religiöse Kriege 🙂

    Wieso?
    Ich wüsste jetzt keine Library die deinen Weg geht - insofern ist es wohl kein religiöser Krieg, sondern da tanzt nur jemand aus der Reihe...

    Aber doch 🙂 Sieh obene Meldung von Volkard 🙂



  • Shade Of Mine schrieb:

    Und genau das ist einer der wenigen Punkte wo ich mit dir nicht übereinstimme.
    Ausser von dir habe ich das Zeiger == out Parameter noch nicht gehört.

    ich war damals auch fast allein, als ich UN ablehnte. und struktogramme. und heute bin ich allein beim ablehnen von UML und nichtkonstanten referenzparametern.

    Shade Of Mine schrieb:

    Für mich ist ein out Parameter durch type& gekennzeichnet - das ist direkt im Code natürlich nicht so ersichtlich, aber ist es mit Zeiger wirklich denn besser?

    es ist halt direkt ersichtlich. das ist superpraktisch. aber das klappt natürlich nur, wenn man es konsequent durchhält.

    Mir fällt kein Beispiel ein, wo es mit einem & klar ist, dass es ein out Parameter ist 😞 Vielleicht kannst du ja ein konkretes Beispiel bringen.

    ich weiß normalerweise, ob ne funktion vom compiler mitgeliefert wurde oder von mir gebaut wurde.
    meine funktionen halten sich dran. müßte aber lange suchen, denn natürlich bevorzuge ich rückgabewerte statt out-parametern.
    erinnern kann ich mich an

    void add(BigInt* result,BigInt& const a,BigInt& const b)
    

    und eine angst, der zeiger ist nur zur sicherheit des aufrufenden, innendrin ist mir das dereferenzieren auch zu mühselig

    void add(BigInt* result,BigInt& const a,BigInt& const b)
    {
       BigInt& c=*result;
       while(...)
       {
          c[i]=a[i]+b[i];//oder so
       }
    }
    

    vor gelegentlichem dereferenzieren in der bibliotheksfunktion oder ner lokalen referenz darf man halt keine scheu haben, wenn man den aufrufern luxus gönnen will (ich bin meist der aufrufer und ich verwöhne mich selber).

    Aber um ehrlich zu sein: ein
    cin>>&i; bzw. cin>>out i;
    würde mich sehr abschrecken...
    Insofern kann man das wohl nicht konsequent durchziehen...

    jo.

    übrigens wechsle ich evtl zum k&r-bracing style. ich baue gerade nen buddy allocator, und da gabs code, der in k&r einfach lesbarer ist.



  • da ist mir gerade eingefallen:
    bei meinem allocator hab ich dauernd sachen wie

    chunk=mergeWithBuddies(chunk,targetOrder);
    ...
    splitChunk(chunk,targetOrder);
    ...
    

    und da war ich oft verwirrt, welche variablen gerade verändert werden. und je weiter ich das problemfeld verstand, desto verwirrter wurde ich. im zuge des ständigen umwerfens von code, kann man sich ja nicht sinnvoll merken, was gerde wiedermal in- und was out-parameter ist. gerade die symmetrie von split und merge drängt auf, sowas zu denken:

    chunk=mergeWithBuddies(chunk,targetOrder);
    ...
    chunk=splitChunk(chunk,targetOrder);
    ...
    

    und da in der unteren zeile nicht chunk= steht, denkt man als nicht-volkard sicherlich oft, daß in

    splitChunk(chunk,targetOrder);
    

    der erste parameter per referenz übergeben wird. der chunk wird solange in kleinere chunks zerhackt, bis die zielgröße erreicht wurde, und einer der kleinen chunks wird zurückgegeben.
    ist aber nicht so. keine rückgabe und der erste parameter ist reiner input.
    würde ich auch nur manchmal referenzparameter als out-parameter verwenden (außer bei swap und cin), dann hätte ich am letzten wochenende bestimmt nen nervenzusammenbruch gekriegt.



  • volkard schrieb:

    übrigens wechsle ich evtl zum k&r-bracing style. ich baue gerade nen buddy allocator, und da gabs code, der in k&r einfach lesbarer ist.

    ?
    Jetzt schockierst du mich aber.
    Ist K&R nicht

    if(foo) {
      something();
    }
    

    ?

    Da musst du mir aber erklären warum du das verwenden willst.

    In der Arbeit verwenden wir diesen Stil - ist zwar PHP - aber ich habe ihn hassen gelernt.

    Was die out Parameter betrifft: da werde ich mir das wohl mal durch den Kopf gehen lassen... Obwohl es mir doch sehr suspekt erscheint.



  • Shade Of Mine schrieb:

    Jetzt schockierst du mich aber.
    Ist K&R nicht

    if(foo) {
      something();
    }
    

    ?
    Da musst du mir aber erklären warum du das verwenden willst.

    hihi. jo, das ist er.
    ist furchbar häßlich, gell?
    die beispiele scheinen echt zu greifen, aber ich hab sie nicht hier. außerdem muß der allokator erst fertig werden. k&r war nämlich in furchtbar komplexen funktionen erst stark. und ich baue eigentlich nie sechszeiler und noch größere monster. und wenn ich die monster kleinhauen kann (zu nullkosten), dann stirb damit auch die k&r-these. dann wäre die schlechtere lesbarkeit von unserem bisherigen klammerstil eher ein anreiz, sich die funktion mal in hinblick auf vereinfachung durch den kopf gehen zu lassen.
    ich poste, wenn ich umgestiegen bin. das liest dann zwar keiner, aber ich mach's trotzdem.


Anmelden zum Antworten