Standardkonstrukor

[hustbaer]

Also ich mach lokale Variablen fast immer const.
In ner 3-zeiler Funktion is das eher weniger interessant. In ner 30-Zeiler Funktion schon.
Wobei es mit nicht darum geht dass ich aus versehen die Variablen ändern könnte. Sondern darum dass ich beim nächsten Mal wo ich den Code lese auch sofort sehe dass die Variable nicht geändert wird.

Bei Parametern von längeren Funktionen greift grundsätzlich natürlich die selbe Logik. Allerdings kann ich mich da einfach nicht dazu überwinden - es sieht für mich einfach so dämlich aus

Und dazu kommt noch: eines unserer Tools ist so dämlich, dass es nicht versteht dass top-level const in der Deklaration und Definition nicht zusammenstimmen muss. Und moppet dann rum wenn man es halt doch unterschiedlich macht. D.h. wenn ich die Variable bei der Definition const haben will, dann müsste ich sie auch bei der Deklaration const machen. Und das finde ich dann wirklich sehr doof.

[Finnegan]

Die Gründe, die für const-By-Value-Parameter sprechen, sind m.E. überzeugend genug um deswegen keine allzu große Diskussion vom Zaun brechen zu müssen oder das gar als eine Art Code Smell anzusehen. Sie helfen, die beabsichtigte Verwendung als nicht-mutable Eingabewerte zu dokumentieren und vermeiden Fehler wie versehentliche Zuweisungen, z.B. durch = vs. ==-Tippfehler.

@hustbaer sagte in Standardkonstrukor:

Bei Parametern von längeren Funktionen greift grundsätzlich natürlich die selbe Logik. Allerdings kann ich mich da einfach nicht dazu überwinden - es sieht für mich einfach so dämlich aus

Allerdings schliesse ich mich auch hier der Meinung an, dass das zusätzliche Schlüsselwort für mehr Code-Rauschen sorgt und das Lesen erschwert. Auch ich finde, dass das irgendwie "komisch" aussieht und mache das vor allem deswegen (und wegen der extra Tipparbeit) ebenfalls nicht durchgängig.

Kein Problem hätte ich allerdings damit, wenn in einer Sprache Parameter per Default const wären und man wie z.B. in Rust ein Keyword wie mut benötigt, wenn man eine modifizierbare Variable haben möchte (das wird es natürlich in C++ nicht mehr geben) - im Gegenteil, das halte ich sogar für einen guten Ansatz.

Funktions-Inputs selbst werden in den meisten Fällen ohnehin nicht verändert (zumindest in dem Code mit dem ich arbeite). Ich finde es sogar eher schlechten Stil, wenn man direkt auf den Parameter-Variablen arbeitet anstatt auf einer dedizierten lokalen Variablen, in der man den Rückgabewert berechnet.

[Th69]

Mit dem top-level const mag jeder halten, wie er/sie/es mag.

Nur die Aussage von @john-0 bzgl. Nichtverwendung von Defaultparametern kann ich nicht nachvollziehen.
Es gibt Konstruktoren (und Funktionen) mit viel mehr Parametern und warum sollen dann beim Aufruf immer alle angegeben werden müssen?

Und gerade bei

Box() : m_width(1), m_height(1), m_length(1) {}
Box(const int w, const int h, const int l) : m_width(w), m_height(h), m_length(l){}

sehe ich das als unnötig an, wenn beide Konstruktoren quasi dasselbe machen (unnötige Codeduplizierung). Machst du das auch bei mehr als 3 Parametern?

[hustbaer]

@Finnegan
Ja, ich denke es ist ziemlich klar dass - aus heutiger Sicht - C++ hier den falschen Default hat. Default sollte mMn. const sein. Bei Membervariablen könnte es etwas lästig werden, aber an so ziemlich allen anderen Stellen wäre default = const mMn. besser. Und ich hätte auch kein echtes Problem damit wenn man sogar Membervariablen extra markieren müsste damit man sie ändern kann.

[Columbo]

@Finnegan sagte in Standardkonstrukor:

Die Gründe, die für const-By-Value-Parameter sprechen, sind m.E. überzeugend genug um deswegen keine allzu große Diskussion vom Zaun brechen zu müssen oder das gar als eine Art Code Smell anzusehen.

Das war auch nicht der Diskussionspunkt. Er hat suggeriert, const soll bei der Deklaration schon im Parameter stehen, weil "Kontrakte".

Ich hatte niemals angedeutet, dass const bei der Funktionsdefinition nicht sinnvoll sein kann, nur dass es bei sehr kurzen Definitionen einfach überflüssig ist (sowie const prinzipiell überflüssig ist, wenn die betroffene Variable sowieso nur einmal verwendet wird (Edit: ok, jetzt kommen gleich wieder irgendwelche kuenstlichen Gegenbeispiele...)).

[Finnegan]

@Columbo sagte in Standardkonstrukor:

@Finnegan sagte in Standardkonstrukor:

Die Gründe, die für const-By-Value-Parameter sprechen, sind m.E. überzeugend genug um deswegen keine allzu große Diskussion vom Zaun brechen zu müssen oder das gar als eine Art Code Smell anzusehen.

Das war auch nicht der Diskussionspunkt. Er hat suggeriert, const soll bei der Deklaration schon im Parameter stehen, weil "Kontrakte".

Ja, das war mir nicht ganz klar. Bei By-Value-Variablen erachte ich das const auch als eine funktionsinterne Information und finde es auch überflüssig und sogar störend, wenn das im Interface mitkommuniziert wird (Mit er Einführung von Modules frage ich mich aber auch ob separate Deklarationen und Definitionen irgendwann überhaupt noch angesagt sind, wenn man nicht unbedingt eine Forward-Deklaration braucht - ist ja schon extra Aufwand).

Ich hatte niemals angedeutet, dass const bei der Funktionsdefinition nicht sinnvoll sein kann, nur dass es bei sehr kurzen Definitionen einfach überflüssig ist

Zur Kenntnis genommen

(sowie const prinzipiell überflüssig ist, wenn die betroffene Variable sowieso nur einmal verwendet wird (Edit: ok, jetzt kommen gleich wieder irgendwelche kuenstlichen Gegenbeispiele...)).

Wenn du schon drum bettelst:

auto quadriere(const int n) {
    return n * n;
}

[hustbaer]

@Finnegan sagte in Standardkonstrukor:

(sowie const prinzipiell überflüssig ist, wenn die betroffene Variable sowieso nur einmal verwendet wird (Edit: ok, jetzt kommen gleich wieder irgendwelche kuenstlichen Gegenbeispiele...)).

Wenn du schon drum bettelst:

auto quadriere(const int n) {
    return n * n;
}

Wieso sollte const hier nicht überflüssig sein?

[Finnegan]

@hustbaer sagte in Standardkonstrukor:

Wieso sollte const hier nicht überflüssig sein?

Es ging mir um ein möglichst leichtgewichtiges Trollbeispiel, in dem die Parameter-Variable eben nicht "nur einmal" (wie @Columbo schrieb) verwendet wird. Daher auch der Smiley mit rausgestreckter Zunge

[*john 0]

@Th69 sagte in Standardkonstrukor:

Mit dem top-level const mag jeder halten, wie er/sie/es mag.

Nur die Aussage von @john-0 bzgl. Nichtverwendung von Defaultparametern kann ich nicht nachvollziehen.
Es gibt Konstruktoren (und Funktionen) mit viel mehr Parametern und warum sollen dann beim Aufruf immer alle angegeben werden müssen?

Dann reden wir über andere Funktionsdeklarationen, und dann ist im konkreten Fall zu beurteilen, ob das sinnvoll ist oder nicht.

Und gerade bei

Box() : m_width(1), m_height(1), m_length(1) {}
Box(const int w, const int h, const int l) : m_width(w), m_height(h), m_length(l){}

sehe ich das als unnötig an, wenn beide Konstruktoren quasi dasselbe machen (unnötige Codeduplizierung).

In der Schnelle habe ich keine Konstruktor Delegation genutzt. Aber Mikrooptimierungen sind Dinge, die man gleich ganz unterlassen sollte, sprich ob das nun Codeduplizierung ist, ist an dieser Stelle relativ egal, und bei umfangreicheren Konstruktoren nutzt man Konstruktor Delegation.

Box (const int w, const int h, const int l) : m_width(w), m_height(h), m_length(l) {}
Box () : Box (1, 1, 1) {}

Machst du das auch bei mehr als 3 Parametern?

Das kommt auf den Konstruktor an. Die Frage ist, wie man sinnvoll ein Objekt konstruiert. Es mag bei C++ zuweilen gute Gründe geben einen Defaultkonstruktor zu definieren, auch wenn das aus der Logik der Objekte sich nicht unbedingt ergibt.

Aber, wie sinnvoll ist es bei einem Quader nicht alle drei Dimensionen anzugeben?

@Columbo sagte in Standardkonstrukor:

@john-0 Das Internet ist überwiegend meiner Meinung, dass const aus deklarativer Sicht vollkommen überflüssig ist, weil jeder Programmierer bestens weiss, wie by-value funktioniert.

Es ist nicht überflüssig, es ist vielleicht nicht notwendig. Es richtet vor allem keinen Schaden an. Es geht darum glasklar zu dokumentieren, was da gemacht wird. Es mag Dir immer klar sein, dass in C++ die Parameterübergabe by Value erfolgt. Ich programmiere aber nicht nur in einer Sprache, und der Code wird nicht nur von Personen gelesen, die jeden Tag ausschließlich C++ nutzen. Weißt Du von jeder von Dir jemals genutzten Sprache (ohne vorher nachzuschauen) wie die Parameterübergabe funktioniert?

Es geht darum Code so zu schreiben, dass er auch noch in Jahren leicht gewartet werden kann, und man vorher nicht erst etliche Dokumentationen durcharbeiten muss.

Es geht nicht darum zu zeigen, was für ein toller Hecht man als Programmierer ist. Was ich an dir problematisch erachte, ist nicht, dass du das anders machst, sondern, dass du dich zu überheblichen Kommentaren hinreißen lässt. Das tun meiner Erfahrung nach nur Personen, die von den Defiziten ihrer eigenen Arbeit ablenken wollen.

[Jockelx]

@john-0 sagte in Standardkonstrukor:

dass du dich zu überheblichen Kommentaren hinreißen lässt. Das tun meiner Erfahrung nach nur Personen, die von den Defiziten ihrer eigenen Arbeit ablenken wollen

Mehr Glashäuser und Steine hab ich wohl noch nie gesehen....

[Columbo]

@john-0 sagte in Standardkonstrukor:

@Columbo sagte in Standardkonstrukor:

@john-0 Das Internet ist überwiegend meiner Meinung, dass const aus deklarativer Sicht vollkommen überflüssig ist, weil jeder Programmierer bestens weiss, wie by-value funktioniert.

Es ist nicht überflüssig, es ist vielleicht nicht notwendig. Es richtet vor allem keinen Schaden an. Es geht darum glasklar zu dokumentieren, was da gemacht wird. Es mag Dir immer klar sein, dass in C++ die Parameterübergabe by Value erfolgt. Ich programmiere aber nicht nur in einer Sprache, und der Code wird nicht nur von Personen gelesen, die jeden Tag ausschließlich C++ nutzen. Weißt Du von jeder von Dir jemals genutzten Sprache (ohne vorher nachzuschauen) wie die Parameterübergabe funktioniert?

Hoer auf mit non sequiturs um dich zu werfen, um deine Totgeburt von einem Standpunkt zu verteidigen.
Was haben andere Sprachen mit C++ zu tun?
Warum sollte ich jemals eine C++ Datei oeffnen und ploetzlich das komplette Typsystem verwechseln, so als ob ein int Parameter eine Referenz ist?
Warum sollten meine Kollegen, nur weil sie nicht "ausschliesslich C++" programmieren, so dermassen ignorant sein, dass sie nicht einmal die Grundsaeule des Typsystems verinnerlicht haben?
Warum vertrittst Du in einem Expertenforum ein Paradigma, dass scheinbar fuer Zusammenarbeit mit absoluten Noobs konzipiert ist?

Es geht darum Code so zu schreiben, dass er auch noch in Jahren leicht gewartet werden kann, und man vorher nicht erst etliche Dokumentationen durcharbeiten muss.

Hast Du Angst, in ein paar Jahren zu vergessen, wie Parameteruebergabe in C++ funktioniert?

Es geht nicht darum zu zeigen, was für ein toller Hecht man als Programmierer ist.

Du musst schon prophylaktisch deine Parameter const markieren weil Du Java nicht von C++ unterscheiden kannst... Du bist eher ein Seestern.

Edit: Das ist ein schlechtes Beispiel, weil Java fundamentale Typen nicht by-reference behandelt. Ich kann mir auf die schnelle tatsaechlich keine Beispielsprache ueberlegen, wo int standardmaessig eine Referenz ist.. was wiederum die Validitaet deines Arguments unterminiert...

[wob]

@Columbo sagte in Standardkonstrukor:

Warum vertrittst Du in einem Expertenforum ein Paradigma, dass scheinbar fuer Zusammenarbeit mit absoluten Noobs konzipiert ist?

"in einem Expertenforum"? Die meisten Threads hier werden von Personen eröffnet, die gerade dabei sind, Grundlagen zu lernen.

Außerdem: was ist schlecht daran, wenn Code auch von absoluten Noobs gelesen werden kann. Nur weil Code nicht von Noobs gelesen werden kann, ist er nicht deswegen besser (natürlich gibt es Fälle, wo der nicht-Noob-kompatible Code besser ist).

Warum sollten meine Kollegen, nur weil sie nicht "ausschliesslich C++" programmieren, so dermassen ignorant sein, dass sie nicht einmal die Grundsaeule des Typsystems verinnerlicht haben?

Ich habe lange genug in der Uni / in einem Forschungsinstitut gearbeitet, wo sehr viele Stundenten hauptsächlich an Ergebnissen interessiert waren und erst während der Diplom/Master/PhD-Arbeit überhaupt mit C++ (teils als 1. Programmiersprache überhaupt) in Berührung gekommen sind. (Fast) niemand davon hat sich jemals für das Typsystem interessiert... Du kannst jetzt sagen, dass diese Leute alle C++ zwar für die Arbeit, aber nicht professionell einsetzen. Schön. Geht aber völlig an meiner Realität vorbei - Noob-Kompatibilität ist wichtig.

[Columbo]

Um die Diskussion mit dem kategorischen Imperativ abzuschliessen: Wer hier, ohne einen Rahmen zu setzen, postuliert, dass es sinnvoll sei, const vor Parameter zu setzen, um auch das schlimmste Greenhorn nicht zu verwirren, der suggeriert folglich, dass dies aus dem selben Grund in allen Bibliotheken und Projekten ueberall so getan werden sollte, was faktisch nirgends der Fall ist, und ausserdem krass schwachsinnig waere. Weil C++ nicht anfaengerfreundlich ist, niemals sein wird, und die Gemeinde sich aus praktischen Gruenden dagegen entschlossen hat, darauf Ruecksicht zu nehmen. Und weil jemand, der const vor Parametern braucht, um nicht verwirrt zu werden, keine genuegende Basis hat, um irgendein groesseres C++ Projekt selbststaendig einsetzen zu koennen.

Ich bin mittlerweile schon skeptisch ob die Praemisse, dass es Leute gibt die int als Referenz missverstehen koennten, ueberhaupt zulaessig ist. Klingt unwahrscheinlich.

[Jockelx]

@wob sagte in Standardkonstrukor:

Noob-Kompatibilität ist wichtig

Und diese Noobs kennen die absoluten Basics der Sprache nicht, aber analysieren genau die Signatur jeder Funktion die sie verwenden? Das geht aber auch an der Realität vorbei.

[wob]

@Jockelx Nein, das tun sie nicht. Aber du bringst denen bei "benutzt möglichst const" bei.

Dass das hier überhaupt geht, ist sehr überraschend:

struct X {
  X(const int some_stupid_name_or_no_name_at_all);
  int i;
};

X::X(int other_name) : i(other_name) {}

int main() { X x(42); return x.i; }

[*john 0]

@Columbo sagte in Standardkonstrukor:

Edit: Das ist ein schlechtes Beispiel, weil Java fundamentale Typen nicht by-reference behandelt. Ich kann mir auf die schnelle tatsaechlich keine Beispielsprache ueberlegen, wo int standardmaessig eine Referenz ist.. was wiederum die Validitaet deines Arguments unterminiert...

Ich mache u.a. HPC und da wird noch immer Fortran recht häufig verwendet, und etliche Personen kennen nur Fortran als Programmiersprache. Nimm einfach den folgenden Code speichere in als parameter.f90 ab, und übersetze ihn mit einem Fortran Compiler.

program parameter
    use iso_fortran_env
    implicit none

    integer :: i = 1

    call foo(i)
    write(output_unit,*) i
contains
    subroutine foo(i)
        integer :: i

        i = i + 1
    end subroutine foo
end program

Wer sich nicht die Mühe machen will, die Ausgabe ist natürlich 2 und nicht 1 wie Columbo das erwarten würde, da Fortran Parameter als Referenz übergibt.

Programmieren ist kein obfuscated c contest.

@Jockelx sagte in Standardkonstrukor:

Mehr Glashäuser und Steine hab ich wohl noch nie gesehen....

Du verwechselt hier eindeutig Ursache und Wirkung.

[Quiche Lorraine]

Eine dumme Frage. Was hält ihr von const Rückgabewerten?

Ab und zu sehe ich nämlich Stilblüten in der folgenden Form.

const bool Foo(const int a, const bool& b = true)

[Quiche Lorraine]

Der Gedanke hinter dem Code scheint dabei folgendermaßen zu sein: "Const Correctness = Ich mach mal überall const dran bis der Compiler meckert"

[Jockelx]

@Quiche-Lorraine

Hier (mit bool) sehe ich zwar keinen Nutzen, aber wenn der Rückgabewert kein bool ist, sondern eine Klasse, dann macht das const schon Sinn.

[SeppJ]

@Quiche-Lorraine sagte in Standardkonstrukor:

Eine dumme Frage. Was hält ihr von const Rückgabewerten?

Ab und zu sehe ich nämlich Stilblüten in der folgenden Form.

const bool Foo(const int a, const bool& b = true)

Gefährliches, veraltetes Halbwissen. Die Absicht war, vor langer, langer Zeit einmal, dass man Vollnoobs, die sowieso nichts damit anfangen könnten, vor an den Haaren herbei gezogenen Fehlern zu schützen. A la

const MyClass foo();

foo() = MyClass();  // Würde dadurch verhindert

Würde niemand mit mehr als 5 Minuten Erfahrung jemals auch nur auf die Idee kommen, muss man also eigentlich gar keine Rücksicht drauf nehmen.

Die Sache ist aber gefährlich geworden mit Move-Semantik, wo es jetzt richtige, sinnvolle Optimierungen in normalem Code verhindert, für den oben genannten nicht-vorhandenen Mehrwert.
Siehe auch: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rf-out

Wenn man das also sieht, weiß man, dass man es mit jemandem zu tun hat, der seit 15 Jahren (C++11 ist viel älter als 2011…) nichts gelernt hat; und auch vorher schon war der const-Rückgabewert von fragwürdigem Nutzen.