Exceptions filtern und weiterleiten

Sone

out schrieb:

Sone schrieb:

Wieso? Ich nutze const wo ich kann. Und damit garantiert man dem Aufrufer und sich selbst, dass der Parameter im Verlauf der Funktion immer denselben Wert hat.

Du hast es nicht verstanden: Wenn du by-value machst, dann weiß der Aufrufer doch schon längst, dass sein Argument auch nach der Funktion noch denselben Wert hat, da das Argument ja kopiert wird, verstehst du?

Das habe ich schon lange kapiert, keine Sorge. Ich weiß, was by-value heißt

Wenn du als Entwickler sichergehen willst, dass der Parameter stets denselben Wert hat, machst du den Parameter trotzdem nicht const:

1. Weil es den Aufrufer verwirrt. Er wundert sich, dass bei by-value der Paramter const ist und will wissen, was es damit auf sich hat.

2. Du legst damit Implementierungsdetails frei. Dass ein Parameter in der Funktion nicht verändert werden darf, geht doch den Aufrufer nichts an. Das Offenlegen von Implementierungsdetails wird als schlechtes objektorientiertes Progammieren angesehen.

Willst du also sichergehen, dass der Parameter stets denselben Wert hat, machst du das so:
void fkt(int i)
{
    const int& ci = i;
    // und erst jetzt beginnt die eigentliche Arbeit der Funktion.
}

Shade Of Mine schrieb:

Mal von dem Prinzip abgesehen, dass man Never Ever Ever Implementierungsdetails verraet.

Na bitte, sowas wollte ich hören.

Kellerautomat

Sone schrieb:

C++11 macht einen Unterschied zwischen prvalue und rvalue. Sonst würde man nicht zwei unterschiedliche Ausdrucksklassen daraus machen.

Dass es hier irrelevant ist, dürfte mehr als offensichtlich sein

Ein rvalue ist entweder ein prvalue oder ein xvalue. Was an meiner Aussage jetzt falsch ist, darfst du mir also erklaeren.

Sone

Kellerautomat schrieb:

Sone schrieb:

C++11 macht einen Unterschied zwischen prvalue und rvalue. Sonst würde man nicht zwei unterschiedliche Ausdrucksklassen daraus machen.

Dass es hier irrelevant ist, dürfte mehr als offensichtlich sein

Ein rvalue ist entweder ein prvalue oder ein xvalue. Was an meiner Aussage jetzt falsch ist, darfst du mir also erklaeren.

Gar nichts. Die hat keiner in Frage gestellt.

Sone schrieb:

Na bitte, sowas wollte ich hören.

Jut. Und noch zum Abschluss: http://www.devx.com/tips/Tip/26546

TyRoXx

Es kommt mir so vor als wüssten einige hier nicht, dass man das schreiben darf:

void f(int a);

void f(int const a) {}

http://www.devx.com/tips/Tip/26546 schrieb:

const in pass-by-value is indeed redundant. The function can't make changes to the original variable anyway, because it has a local copy thereof. Now one can argue that even in that case, the use of const documents the fact that the function doesn't change its local copy. However, do we really care about this? If you are the implementer of the function, you probably do but you certainly don't need to document this fact, as it is merely an implementation detail, not a part of the interface. Users of this function certainly don't care; all they need to know is that the original variable can't be altered, and the use of pass-by-value, with or without const, already guarantees that. To conclude, the use of const in pass-by-value is an example of over-specification that exposes an implementation detail. In general, exposing implementation details is bad object-oriented programming practice.

Der Typ weiß das auch nicht.
Typischer Blödsinn eines "real programmer", der den Sinn von const nicht verstanden hat. Der verwendet wahrscheinlich delete bei Arrays und vergleicht float mit == . Ist ja schließlich in seinem (kurzen und oberflächlichen) Programmiererdasein noch nie schiefgegangen.

Was hast du an dem Text auszusetzen?

TyRoXx

out schrieb:

Was hast du an dem Text auszusetzen?

The function can't make changes to the original variable anyway, because it has a local copy thereof.

Darum geht es auch gar nicht.

Now one can argue that even in that case, the use of const documents the fact that the function doesn't change its local copy.

Das dokumentiert nicht, sondern erzwingt, dass die Variable nicht geändert wird. Der Compiler hilft einem, Fehler zu vermeiden. Der Benutzer der Funktion bemerkt davon nichts.

However, do we really care about this?

Ja

If you are the implementer of the function, you probably do but you certainly don't need to document this fact, as it is merely an implementation detail, not a part of the interface.

Man kann const schreiben, aber man muss nicht. Ja, und weiter?

Users of this function certainly don't care; all they need to know is that the original variable can't be altered, and the use of pass-by-value, with or without const, already guarantees that.

Ach

To conclude, the use of const in pass-by-value is an example of over-specification that exposes an implementation detail.

Das wird nichts exposed.

In general, exposing implementation details is bad object-oriented programming practice.

Hauptsache, mal irgendein Buzzword genannt. Muss ja nichts mit dem Thema zu tun haben.

Ich sehe in der Antwort Null Inhalt. Es wird behauptet, das Implementationsdetail const müsse in die Schnittstelle übergehen, was nicht stimmt.

Sone

TyRoXx schrieb:

Now one can argue that even in that case, the use of const documents the fact that the function doesn't change its local copy.

Das dokumentiert nicht, sondern erzwingt, dass die Variable nicht geändert wird. Der Compiler hilft einem, Fehler zu vermeiden. Der Benutzer der Funktion bemerkt davon nichts.

Genau das war mein Gedankengang.

Shade Of Mine

Die Deklaration einer Funktion ist nicht die einzige Schnittstelle die es gibt.
[PS: Schnittstelle ist hier das falsche Wort. Eher oeffentliches Aufscheinen der Signatur - das waere wohl besser]

Nur weil etwas nicht teil des oeffentlichen Interfaces fuer Anwender ist, ist es noch lange kein verstecktes Implementierungsdetail.

Leute arbeiten mit dem Code und wenn einmal die Signatur so aussieht und einmal so und dann vielleicht auch noch teilweise inkonsistent mit der Dokumentation ist - dann hat man ein Problemfeld erschaffen, dass ohne const nicht existieren wuerde.