Problem mit get-Methode

[dd++ 0]

Swordfish schrieb:

Wovon soll da irgendwer 'nen Drehwurm bekommen?!

in diesem Konstruktor

matrix::matrix(int n, int m) : n(n), m(m)

gelten folgende Regeln:

3.4.1 Unqualified name lookup
11 During the lookup for a name used as a default argument (8.3.6) in a function parameter-declaration-clause or used in the expression of a mem-initializer for a constructor (12.6.2), the function parameter names are visible and hide the names of entities declared in the block, class or namespace scopes containing the function declaration. [ Note: 8.3.6 further describes the restrictions on the use of names in default arguments. 12.6.2 further describes the restrictions on the use of names in a ctor-initializer. —end note ]
12.6.2 Initializing bases and members
2 In a mem-initializer-id an initial unqualified identifier is looked up in the scope of the constructor’s class and, if not found in that scope, it is looked up in the scope containing the constructor’s definition. [ Note: If the constructor’s class contains a member with the same name as a direct or virtual base class of the class, a mem-initializer-id naming the member or base class and composed of a single identifier refers to the class member. A mem-initializer-id for the hidden base class may be specified using a qualified name. —end note ] Unless the mem-initializer-id names the constructor’s class, a non-static data member of the constructor’s class, or a direct or virtual base of that class, the mem-initializer is ill-formed.
12 Names in the expression-list or braced-init-list of a mem-initializer are evaluated in the scope of the constructor for which the mem-initializer is specified. [ Example:
class X {
int a;
int b;
int i;
int j;
public:
const int& r;
X(int i): r(a), b(i), i(i), j(this->i) { }
};
initializes X::r to refer to X::a, initializes X::b with the value of the constructor parameter i, initializes X::i with the value of the constructor parameter i, and initializes X::j with the value of X::i; this takes place each time an object of class X is created. —end example ] [ Note: Because the mem-initializer are evaluated in the scope of the constructor, the this pointer can be used in the expression-list of a mem-initializer to refer to the object being initialized. —end note ]

in der mem-initializer-list im Konstrukor kann der Compiler also n und n noch auseinanderhalten, aber spätestens hier ist dann der Wurm drin:

void print(int n, int m);

der Compiler führt das dann zwar aus, aber es ist besser, die Member n und m anders zu benennen als die Funktionsparameter, denn in der Funktion print sind die Member n und m hidden und es geschehen merkwürdige Dinge

[Swordfish]

...

[Sone]

Noch einmal: Da ist für den Compiler alles völlig klar.

Und auch für den C++-Programmierer: Denn die Faustregel ist: Zuerst werden in inneren, und dann in äußeren Scopes gesucht. Und in der Initialisierungsliste lässt sich anhand der Syntax und logischen Gegebenheiten (wie der, dass Funktionsparameter nicht in der Initialisierungsliste "initialisiert" werden können) eben die jeweiligen Namen deduzieren.

[dd++ 0]

ihr würded also empfehlen, die Benennung der Member und Funktionsparameter beizubehalten?

class matrix
{
private:
    int n, m;
    int** feld;

public:
    matrix(int n, int m);
    ~matrix();
    void print(int n, int m);
    void input();
    int getVal(int n, int m);
};

[Sone]

ihr würded also empfehlen, die Benennung der Member und Funktionsparameter beizubehalten?

Wir haben gar nix empfohlen und auch nichts suggeriert. Ich würde beispielsweise, tatsächlich um ein schnelleres Verstehen des Codes zu fördern, die Funktionsparameter mit Unterstrichen o.ä. entsprechend Kennzeichnen. Wichtig ist, dass man diesen Stil dann konsequent beibehält.

[Nathan]

Sone schrieb:

Ich würde beispielsweise, tatsächlich um ein schnelleres Verstehen des Codes zu fördern, die Funktionsparameter mit Unterstrichen o.ä. entsprechend Kennzeichnen. Wichtig ist, dass man diesen Stil dann konsequent beibehält.

Bitte nicht schon wieder diese Diskussion!
Ich würde generell nicht n und m verwenden, sondern irgendetwas wie width, height oder rows, columns oder so.

[Sone]

Nathan schrieb:

Sone schrieb:

Ich würde beispielsweise, tatsächlich um ein schnelleres Verstehen des Codes zu fördern, die Funktionsparameter mit Unterstrichen o.ä. entsprechend Kennzeichnen. Wichtig ist, dass man diesen Stil dann konsequent beibehält.

Bitte nicht schon wieder diese Diskussion!
Ich würde generell nicht n und m verwenden, sondern irgendetwas wie width, height oder rows, columns oder so.

Aha, du hast keine Lust auf die Diskussion, förderst sie aber durch deine Anteilnahme...

Persönlich könnte ich die Variablen leichter ihrem Zweck zuordnen, wenn ich sie auf die Membervariablen "abbilden" kann, aber das ist Geschmackssache.
(Dementsprechend würde ich auch den Member zu mWidth & co. o.ä. umbenennen)

[Nathan]

Sone schrieb:

Aha, du hast keine Lust auf die Diskussion, förderst sie aber durch deine Anteilnahme...

Nein, ich meine die "Membervariablen mit m, m_, _ vorne, _ hinten oder gar nicht kennzeichnen und Parallelen zur Ungarischen Notation"-Diskussion.

[bandchef]

Sone schrieb:

Noch einmal: Da ist für den Compiler alles völlig klar.

Wenn nun für den Compiler alles völlig klar ist, warum geht dann mein Code nicht?

Wo ist denn nun der Fehler?

Ahhhh!

Ich inkrementiere m, nicht i. Das war der Fehler!

[Sone]

Wenn nun für den Compiler alles völlig klar ist, warum geht dann mein Code nicht?

WTF?