const string * == const string * const
-
Es gibt drei Anwendungsfälle für by-Value:
1. Kleine, trivial kopierbare Typen: Nur in diesem Fall greift die Debatte. Und das Argument, dass man das besser von Outputparametern unterscheiden kann, greift eh nur, wenn man Outputparameter hat (was bei mir fast nie auftritt). Das heißt wir diskutieren hier über einen minimalen Anwendungsfall. Und bei diesem minimalen Anwendungsfall kann man ruhig einmal genauer hingucken. Zusätzlich schränkt const den Einsatz ein, oft verändere ich diese Argumente (s. 2).
2. Große, kostpielige kopierbare Typen bei denen man eine Kopie in der funktion verändern möchte: Wenn man eine Kopie innerhalb der Funktion braucht um sie lokal zu verändern. const macht dann da absolut keinen Sinn.
3. in-Parameter: Ähnlich wie 2, die Kopie macht der Compiler beim Aufruf, um sie ins Ziel zu moven, dürfen sie nicht const sein.
-
Arcoth schrieb:
Nein, und wenn du deine Ansicht nicht änderst, wird mit dir keiner arbeiten wollen. Denn abgesehen von dir findet das so gut wie keiner lesbarer. Du ziehst an den Haaren irgendeinen Firlefanz herbei um dein längst widerlegtes Argument noch über Wasser zu halten.
lol
"explizit ist besser als implizit" - und wenn ein einfaches "const" meine Intention als Programmierer ohne irgendwelche Nebenwirkungen verexplizifiziert, wird das von mir genutzt, basta.
-
Nathan schrieb:
Es gibt drei Anwendungsfälle für by-Value:
1. Kleine, trivial kopierbare Typen: [...]In jedem Fall, wo das Profiling einen zu vernachlässigenden Einfluß auf die Komplexität ergibt, entscheide ich mich für gewöhnlich für by-value. Warum für 0.1% mehr Performance den Code mit Sonderzeichen verunhübschen ? Optimieren kann man nötigenfalls immer noch.
-
großbuchstaben schrieb:
Nathan schrieb:
Es gibt drei Anwendungsfälle für by-Value:
1. Kleine, trivial kopierbare Typen: [...]In jedem Fall, wo das Profiling einen zu vernachlässigenden Einfluß auf die Komplexität ergibt, entscheide ich mich für gewöhnlich für by-value. Warum für 0.1% mehr Performance den Code mit Sonderzeichen verunhübschen ? Optimieren kann man nötigenfalls immer noch.
Lassen wir mal die Performance komplett außen vor:
Im generischen Code kann man by-Value für pass-Parameter* nicht verwenden, da Objekte ja evtl. nicht kopierbar sind.
Bei nicht kopierbaren Parametern kann man by-Value ebenfalls nicht verwenden.
Es bleiben also nur noch nicht generische Funktionen mit kopierbaren Objekten übrig. Das heißt die Regel ist schon einmal nicht einheitlich. Alle nicht arithmetischen Typen als pass-Parameter by-Const-Reference, schon. Wir müssen also mehr nachdenken:
Ist der Typ kopierbar? Oh, wo war die Datei doch gleich wo der war... Ah, hier. Kopierkonstruktor, Kopierkonstruktor, nein keiner deklariert, aber der hat eine basisklasse. Wo kommt die denn jetzt her? Ist die kopierbar? Nein, auch kein Kopierkonstruktor, die hat aber einen Member x. Ich glaub x, war kopierbar. *compilieren* Verdammt, x war nicht kopierbar.
Im Gegensatz dazu:
Ist der Typ char/int/float? Nein, pass-by-Value.
Und wenn man jetzt die Performance dazu nimmt: Es macht vielleicht nicht viel aus. Aber a) ist das in High-Performance-Code evtl. schon zu viel (Stell dir ein Spiel vor, was in jedem Frame die komplette Liste aller Game-Objekte kopiert!) und b) schadet ein by-Reference nicht (Wenn du keine Sonderzeichen magst, programmier in BASIC!) und man kann es intuitiv ohne nachzudenken hinschreiben.*D.h. wird innerhalb der Funktion nicht verändert und auch nirgendwo hinkopiert.
-
großbuchstaben schrieb:
basta
Wozu noch diskutieren?
Es ist alles gesagt: im Thread ist klar geworden, das eine klare Mehrheit die erste Variante für deutlich lesbarer hält.
Jetzt kann der Leser selber entscheiden, ob er 1) lieber selber seinen Code gut lesen können möchte oder 2) andere ihn verstehen können sollen.
(Wobei 2) natürlich idR nicht ausschließt, dass man den Code selber gut lesen kann, im Gegenteil)
Fällt die Entscheidung auf 2), läßt man das const weg. Fertig!
-
Jockelx schrieb:
Es ist alles gesagt: im Thread ist klar geworden, das eine klare Mehrheit die erste Variante für deutlich lesbarer hält.
nur wird Wahrheit selten demokratisch entschieden.
-
großbuchstaben schrieb:
Jockelx schrieb:
Es ist alles gesagt: im Thread ist klar geworden, das eine klare Mehrheit die erste Variante für deutlich lesbarer hält.
nur wird Wahrheit selten demokratisch entschieden.
Es geht hier darum, ob dein Code für andere lesbar ist. Und mit andere meine ich andere, nicht dich. Und wenn die Mehrheit der Anderen den Code nicht für lesbar hält, dann ist dein Code eben nicht lesbar - per Definition.
-
Wobei er eig. Recht hat, man kann seine Meinung nícht mit Lesbarkeit widerlegen.
Was gut lesbar ist, ist eine Frage der Gewohnheit. Wären wir es alle gewohnt, const davor zu packen, könnten wir es auch problemlos lesen.
Allein mit der Lesbarkeit zu argumentieren, reicht leider nicht.
-
Nathan schrieb:
Und wenn man jetzt die Performance dazu nimmt: Es macht vielleicht nicht viel aus. Aber a) ist das in High-Performance-Code evtl. schon zu viel
wenn es die Laufzeit um 0.1% erhöht, macht es nicht viel aus. Von was Anderem ist ja nicht die Rede.
Nathan schrieb:
und b) schadet ein by-Reference nicht
es stört die Lesbarkeit an Stellen, wo es überflüssig ist.
Nathan schrieb:
(Wenn du keine Sonderzeichen magst, programmier in BASIC!) und man kann es intuitiv ohne nachzudenken hinschreiben.
Ich schreibe aber keinen Code, ohne nachzudenken. So was fällt einem irgendwann auf die Füße.
Im Gegenteil, ich überarbeite Code öfter mal nur, um die Lesbarkeit zu optimieren.nein, ich habe nichts gegen Sonderzeichen - wenn es der Transparenz dient, ist knappe Notation sogar sehr angenehm. Aber die Entscheidung, in was für Sprachen ich programmiere, überläßt Du besser mir.
-
Nathan schrieb:
Allein mit der Lesbarkeit zu argumentieren, reicht leider nicht.
Doch, natürlich.
Ungarische Notation oder 'C' vor Klassen oder das const hier wird von der Mehrheit als schlecht lesbar empfunden.
Und von daher ist es auch legitim hier davon abzuraten.
-
großbuchstaben, wärst du ernsthaft an einer Diskussion interessiert, hättest du mindestens eines meiner Argumente gelesen und wärst darauf eingegangen.
Stattdessen pickst du dir den am einfachsten zu widerlegbaren Punkt "alle machen es" raus, reitest 2 Seiten darauf herum und lenkst mit "Demokratie" und anderem Blabla vom Thema ab.
Das ist genau was ich mit "scheint leider nichts zu bringen" meinte. Mir wird es zu blöd, aber es gibt wohl genügend Leute, die ihre Zeit weiter verschwenden wollen
-
Jockelx schrieb:
Nathan schrieb:
Allein mit der Lesbarkeit zu argumentieren, reicht leider nicht.
Doch, natürlich.
Ungarische Notation oder 'C' vor Klassen oder das const hier wird von der Mehrheit als schlecht lesbar empfunden.
Und von daher ist es auch legitim hier davon abzuraten.Ja, aber das Hauptargument dagegen ist nicht Lesbarkeit.
Bei der ungarischen Notation ist das die schlichte Sinnlosigkeit und fast unmögliche Umsetzung in C++, bei const ist das ebenfalls die Sinnlosigkeit.
Denn lesbar ist das, was für einen gewöhnt ist.
Früher war ich ein großerFanVonCamelCase. Mittlerweile kann ich das gar nicht mehr lesen. "Lesbar" ist kein konstantes Attribut, "lesbar" ist etwas was mit der Gewöhnung zu tun hat.
-
Nach meiner Erfahrung ist man aber ein Gewohnheitstier, und sollte sich daher keinen Stil angewöhnen der sehr ungewöhnlich ist. Es sei den man programmiert wirklich nur als Einzelkämpfer.
-
@großbuchstaben
Dass es null Informationsgehalt hat, ist mittlerweile wohl hoffentlich klar. Die Definition kann das top-level const nämlich auch weglassen, selbst wenn es in der Deklaration vorhanden war. Weil es eben wie schon mehrfach erwähnt wurde nicht mit zur Signatur gehört.großbuchstaben schrieb:
seit wann entscheiden wir denn demokratisch, was ich lesbarer zu finden habe ?
Aber egal. Wer ein wirklich gutes Gegenargument (außer "alle machen aber X ...") hat, kann sich ja melden.
Damit dass du selbst das top-level const auch bei der Deklaration dranschreibst, trainierst du dir bloss ab es auch anders schnell und ohne Anstrengung lesen zu können.
Da der super-mega-überwiegende Grossteil allen Codes aber gerade kein top-level const verwendet, trainierst du dir also an den super-mega-überwiegende Grossteil allen Codes schlecht lesen zu können.Macht das Sinn?
Nur wenn du Masochist bist, oder selten bis nie fremden Code liest. In beiden Fällen erübrigt sich mMn. die Diskussion.
In allen anderen Fällen sollte das Argument "macht aber keiner so wie du" wesentlich schwerer wiegen als das Argument "ich finds aber so besser".
Weil dein "besser" eben kein echter Vorteil ist. Wenn da kein "&" steht, ODER vor dem "&" ein const steht, ist klar, dass es kein Output-Parameter ist. Wenn man ein unbeschädigtes Sehzentrum hat, kann man das mit etwas Übung mit einem Blick erfassen.
-
ps:
großbuchstaben schrieb:
Aber die Entscheidung, in was für Sprachen ich programmiere, überläßt Du besser mir.
Du überschätzt dich und die Qualität deine Einschätzung bestimmter Dinge ziemlich. Vielleicht solltest du bestimmte Entscheidungen lieber nicht selbst treffen, sondern dich nach anderen, erfahreneren und schlaueren Leuten richten.
Aber hey. Ich muss mit grosser Wahrscheinlichkeit nie ein von dir geschriebenes Programm lesen oder gar warten. => Tu was du glaubst.
-
hustbaer schrieb:
Du überschätzt dich und die Qualität deine Einschätzung bestimmter Dinge ziemlich. Vielleicht solltest du bestimmte Entscheidungen lieber nicht selbst treffen, sondern dich nach anderen, erfahreneren und schlaueren Leuten richten.
wieso denn gleich persönlich werden?
Unsicher geworden?hustbaer schrieb:
Ich muss mit grosser Wahrscheinlichkeit nie ein von dir geschriebenes Programm lesen oder gar warten.
mach dir keinen Kopf, wir haben im Augenblick ohnehin keinen Personalbedarf.
-
wieso denn gleich persönlich werden?
Du scheinst einfach nicht einsehen zu wollen, dass so gut wie jeder kompetente Entwickler dir nicht zustimmt. Genug Argumente wurden mittlerweile genannt.
- Es ist laut allgemeinem Konsens weniger lesbar
- Für den Caller vollkommen irrelevant
- Für den Callee bei der Deklaration redundant und irrelevant
Nexus schrieb:
großbuchstaben, wärst du ernsthaft an einer Diskussion interessiert, hättest du mindestens eines meiner Argumente gelesen und wärst darauf eingegangen.
Stattdessen pickst du dir den am einfachsten zu widerlegbaren Punkt "alle machen es" raus, reitest 2 Seiten darauf herum und lenkst mit "Demokratie" und anderem Blabla vom Thema ab.
-
Arcoth schrieb:
Du scheinst einfach nicht einsehen zu wollen, dass so gut wie jeder kompetente Entwickler dir nicht zustimmt.
und du scheinst nicht einsehen zu wollen, daß für mich der Geschmack der Mehrheit kein Kriterium ist. Und jetzt ?
-
Ist Konsistenz mit Code anderer ein Kriterium für dich?
-
kommt drauf an. Ich passe mich gerne einem anderen Stil an, falls dieser nennenswerte Vorteile gegenüber meinem eigenen Stil hat, oder wenn er qua code style policy vorgegeben ist.
Die Argumente "alle machen es so" oder "das const ist für den Compiler überflüssig" sind mir allerdings deutlich zu schlicht. Letztlich stehe ich für meinen Code gerade und kann jede stilistische Entscheidung wohlbegründen.
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.
