const string * == const string * const



  • großbuchstaben schrieb:

    ps. Ich habe einige Jahre lang TeX-Packages für den Produktiveinsatz programmiert (rohes TeX, nicht LaTeX) - da lernt man, sich bei jedem Makro genau zu überlegen, wie man es benennt, formatiert und kommentiert, und welchen Wert ein einheitlicher, wohlüberlegter code style hat - andernfalls wäre man schnell aufgeschmissen.

    Ich habe einige Jahre in BASIC programmiert und habe da genau gelernt, daß Variablennamen maximal zwei Buchstaben haben dürfen. Bin jetzt nicht sicher, ob SeppJ glücklich wäre, wenn ich daraus ableiten würde, wie man in C++ programmieren sollte.
    So, Du hast also für Tex "programmiert". Und Du bist Dir sicher, daß Du den Tex-Stil in C++ einsetzen solltest. Ist Tex von C++ nicht noch weiter weg als BASIC?



  • die grundlegenden Tugenden guten Programmierstils

    ("programmer's intention", Kommentierung, "explizit ist besser als implizit", Modularisierung, "sprechende Bezeichner" usw) lassen sich auf fast jede Programmiersprache übertragen.

    Lektion 1, die mir meine Praxis in verschiedenen Programmiersprachen erteilt hat, war: "Mach' niemals etwas, bloß weil alle es machen".

    Und Lektion 2: Ich suche mir den Kreis meiner Lehrmeister sorgfältig aus. Poster mit -zigtausend Posts gehören übrigens für gewöhnlich nicht dazu.



  • Aber das Prinzip von Konsistenz ist dir schon klar, oder? Wir bleiben bei rot stehen und gehen bei grün los. Warum nicht andersrum? Rechtsverkehr oder Linksverkehr? Völlig egal, Hauptsache es ist einheitlich. Und wenn sich heraus stellt, dass man Blindenhunden leichter beibringen kann bei rot loszulaufen und damit die umgedrehten Farben besser sind macht es trotzdem keiner, das würde ein gigantisches Chaos verursachen.
    Mein Punkt ist, dass "Alle machen das so" ein gutes Argument ist. Dagegen muss man erstmal ankommen, was durchaus möglich ist, aber deine bisherigen Argumente reichen dafür nicht. Jetzt stellt sich die Frage, ob du den Anspruch hast andere zu überzeugen oder du lieber per Abkapseln das Konsistenzargument schwächst.

    PS: Wie gut dass es für mich keinen Beitragszähler gibt 😃



  • niemand muß sich umgewöhnen, wenn er ein Programm liest, in dem by-value Parameter ge-const-et sind. Genauso wenig, wie sich jemand umgewöhnen müßte, wenn an jeder Ampel ein Schild "bei rot gehen, bei grün stehenbleiben" angebracht wäre.

    leider wieder kein gutes Argument, nicht zu const'en. Aber vielleicht kommt ja noch ein erstes.



  • Korrektur des obigen Postings:

    Genauso wenig, wie sich jemand umgewöhnen müßte, wenn an jeder Ampel ein
    Schild "bei grün gehen, bei rot stehenbleiben" angebracht wäre.



  • großbuchstaben schrieb:

    leider wieder kein gutes Argument, nicht zu const'en. Aber vielleicht kommt ja noch ein erstes.

    Wie wärs mit einem simplen, wie schon von mir genannt: Ich will by-Value Parameter innerhalb der Funktion verändern.



  • großbuchstaben schrieb:

    Genauso wenig, wie sich jemand umgewöhnen müßte, wenn an jeder Ampel ein Schild "bei rot gehen, bei grün stehenbleiben" angebracht wäre.

    Als ob viele Menschen ein Schild lesen würden. In der Anfangszeit gäbe es wohl nicht wenige Tote. Du unterschätzt auch wie sehr wir Menschen Gewohnheitstiere sind. Wenn man sich etwas angewöhnt hat, ist es schwer wieder abzustellen. Dazu gehört auch schlechter Codestil.

    Man kann sich über das "const" bei by-value Parametern streiten, doch es gibt zumindest "weiche" Kriterien gegen das const an dieser Stelle. Die werden aber von dir schlicht ignoriert.

    • Es ist im Gegensatz zu Klammerung ein fast einheitlich üblicher Stil (Bei Klammerung gibt es dahingehend einige Stile, da kann man gut auswählen).
    • Unnötige Erhöhung der Lesekomplexität. Die Angabe hat keinen Mehrwert, warum noch ein Schlüsselwort zusätzlich schreiben?
    • Obwohl Kopie, kann ich diesen Wert lokal nicht verändern? (Warum?)

    Grundsätzlich bin ich der Ansicht das man unnötige Angaben, die keinerlei Mehrwert haben auch sein lassen sollte. Ein const hat an vielen Stellen einen Mehrwert, nur hier eben nicht.

    großbuchstaben schrieb:

    niemand muß sich umgewöhnen, wenn er ein Programm liest, in dem by-value Parameter ge-const-et sind.

    Es ist sehr ungewohnt ein Schlüsselwort zu sehen, das keinen Mehrwert liefert. Ich würde zumindest etwas länger beim Lesen bei der Parameterliste verharren. Und es ist ein ganz blödes Argument etwas nur deshalb nicht so zu machen, weil es andere machen. Es sollte auch einen guten Grund dafür geben. Und der ist hier nicht gegeben.



  • überzeugt mich alles nicht. Die "programmer's intention" klar auszudrücken ist zumindest mir wichtiger.


  • Mod

    großbuchstaben schrieb:

    Die "programmer's intention" klar auszudrücken ist zumindest mir wichtiger.

    Da musste ich echt schmunzeln, bei dem Gedanken dass in diesem Thread mindestens zwanzig mal angedeutet wurde dass dadurch keine Intention ausgedrückt wird, denn dem Caller ist es ~~sch***~~schnurzegal ob die Kopie verändert wird und in der Deklaration ist es dem Callee egal.



  • ja klar, einen Parameter nicht als Rückgabe verwenden zu wollen ist ja auch keine Intention 🙄



  • großbuchstaben schrieb:

    ja klar, einen Parameter nicht als Rückgabe verwenden zu wollen ist ja auch keine Intention 🙄

    Es ist ja nicht so, dass die Intention durch das fehlende const nicht ausgedrückt wird. Sie ist ja so oder so klar erkennbar.
    Ein const davor hinzuschreiben bringt lediglich eine bereits vorhandene Information nochmal zum Ausdruck, hat allerdings zur Folge, dass
    a) der Leser, der das nicht gewohnt ist - d.h. die Mehrheit, verwirrt ist.
    b) der Implementierer eingeschränkt ist, da er nicht kopieren kann, da er die Kopie nicht veändern kann.
    c) man unnötigerweise alle Funktionen ohne Outputparameter - d.h. die Mehrheit, mit komplett unnötigen Informationen vollklatscht, die die Zeilenlänge erhöhen, mehr zu tippen sind und den Lesefluss stören.



  • ad a) was ist an einem const verwirrend ?

    ad b) ???

    ad c) Bei mir nicht. Spätestens ab 3 Parameter bekommt bei mir jeder Parameter seine eigene Zeile, meistens schon ab 2.


  • Mod

    großbuchstaben schrieb:

    ad a) was ist an einem const verwirrend ?

    "Hey, Peter, meiner Freundin fehlt komischerweise ein Höschen. Schmeißt' mal ein Bier rüber?"
    <Peter schmeißt das Bier> "Ja und weiter?"
    "Nichts."
    "Äh, ok...?"
    Peter ist verwirrt. Wollte sein Freund ihm irgendetwas andeuten? Warum hat er das wohl gesagt? Denkt er, Peter klaut die Höschen seiner Freundin?

    Für den Rest des Abends bleibt das stehts in Peters Hinterkopf.
    ~
    Edit: Logik korrigiert.~



  • großbuchstaben schrieb:

    ad a) was ist an einem const verwirrend ?

    Es lässt ihn inne halten und überlegen. Sollte das vielleicht eine Referenz werden? Was macht das const da?

    ad b) ???

    Fataler Fail meinerseits.
    Meinte: , da er die Kopie nicht verändern kann.



  • Nathan schrieb:

    Meinte: , da er die Kopie nicht verändern kann.

    Wieso nicht? In der Definition kann er ja das const weglassen.


  • Mod

    nwp3 schrieb:

    In der Definition kann er ja das const weglassen.

    Auch deswegen ist const bei der Funktionsdeklaration so ein Schwachsinn: Es kann falsche Implementierungsdetails impizieren.



  • nwp3 schrieb:

    Nathan schrieb:

    Meinte: , da er die Kopie nicht verändern kann.

    Wieso nicht? In der Definition kann er ja das const weglassen.

    Außer bei inlines und Templates.
    Und schon hat man wieder einen Sonderfall.

    @großbuchstaben:
    Was sagst du zu

    man unnötigerweise alle Funktionen ohne Outputparameter - d.h. die Mehrheit, mit komplett unnötigen Informationen vollklatscht

    .
    Du bist dort bisher nur auf die Zeilenlänge eingegangen.


  • Mod

    Außer bei inlines und Templates.

    Das ist doch völlig falsch?
    Edit: 💡
    Solltest du trotzdem ein wenig klarer schreiben.



  • Heute hab ichs aber.
    Außer bei inline u.d Templates, wo (bei mir jedenfalls) Deklaration und Definition nicht getrennt werden.


Anmelden zum Antworten