Ein Suchbild:

Window::Window(size_t width, size_t height, char c)
    : data(NULL), width(width), height(height)
    {
        size_t length = width * height;
        data = new char[length];
        fill(c);
    }

vs.

Window::Window(size_t width, size_t heigth, char c)
    : data(NULL), width(width), height(height)
    {
        size_t length = width * height;
        data = new char[length];
        fill(c);
    }

In den meisten Fällen findet man Fehler durch aufmerksames Quelltext lesen recht zuverlässig. Aber der Fehler im zweiten Code-Block hatte sich dann doch meiner Wahrnehmung entzogen.

Der logisch wasserdichte Code stürzte bei der Ausführung einfach mal ab ;).

Mit m_ wäre das nicht passiert...

Grüße...

Heiko

öhm... bin ich blind? Also... die beiden blöcke sind doch vollkommen identisch?

height <-> heigth

Die Moral von der Geschicht': markiert die Member als solche ('m_'-präfix oder '_'-suffix). Der Code liest sich auch irgendwie besser ...

Gruß
Werner

Nicht ganz - aber man muß wirklich sehr genau hinsehen, um den Fehler zu erkennen (oder einen Text-Editor seiner Wahl bitten, den Fehler besser hervorzuheben - Tip: er betrifft die Variablennamen).

Ein (Syntax-)Fehler ist es ja nicht, da hilft auch der beste Texteditor nicht. Das war ja das Problem - ansonsten nenne mir mal bitte den Texteditor, der das kann

Das Problem in der Sache entstand in erster Linie aus der Parameterüberladung. size_t heig*th* ist als Parameter gültig und könnte im Konstruktor (und in der Initialisierungsliste) verwendet werden. heig_ht_ existiert aber bereits durch die Deklaration und initialisiert sich in der Initialisierungsliste mit sich selbst (undefiniert), da die Parameterüberladung de facto ja nichts stattfindet -> Das Programm verhält sich korrekt, nur eben nicht, wie erwartet.

Hinzu kommt noch die Unzulänglichkeit der menschlichen Wahrnehmung

Grüße...

m_Heiko

CStoll schrieb:

Nicht ganz - aber man muß wirklich sehr genau hinsehen, um den Fehler zu erkennen (oder einen Text-Editor seiner Wahl bitten, den Fehler besser hervorzuheben - Tip: er betrifft die Variablennamen).

Ein (Syntax-)Fehler ist es ja nicht, da hilft auch der beste Texteditor nicht. Das war ja das Problem - ansonsten nenne mir mal bitte den Texteditor, der das kann

Ich dachte auch nicht an automatische Analysen, sondern eher an Suchen/Ersetzen (würde für dein Beispiel ausreichen, um den Unterschied zu erkennen - in der Praxis muß man erstmal wissen, was man suchen will)

Bei m_var finde ich aber auch, dass es den Lesefluss stört, weil es aussieht wie zwei verschiedene Token, einmal m und einmal var, nix zusammenhängendes halt. Aber ist ja äußerst subjektiv und jeder wie er mag

Ein (Syntax-)Fehler ist es ja nicht, da hilft auch der beste Texteditor nicht. Das war ja das Problem - ansonsten nenne mir mal bitte den Texteditor, der das kann

Eclipse hinterlegt mir alle Vorkommen eines Namens, wenn ich draufklick.

...
...Mit m_ wäre das nicht passiert...

Werner Salomon schrieb:

Superbeispiel ich hab's nach den ersten beiden Durchlesen wirklich nicht gefunden.

Die Moral von der Geschicht': markiert die Member als solche ('m_'-präfix oder '_'-suffix). Der Code liest sich auch irgendwie besser ...
...

Was wäre denn mit Präfix besser geworden ?

Window::Window(size_t width, size_t heigth, char c)
    : data(NULL), width(width), m_height(m_height)
...

geht doch genauso in die Hose.

MEINE Moral von der Geschicht: Verwende niemals gleichlautende Variablen.
SOWAS macht immer Probleme.

Gruß,

Simon2.

Die Moral von der Geschicht': markiert die Member als solche ('m_'-präfix oder '_'-suffix).

Oder '_[:lower-case-char:]'-präfix

Andererseits, sollte es egal sein ob height nun ein Member oder eine Konstante oder so ist...

Weitere Alternative: konsistent height() bzw. get_height() nutzen.