Membervariablen einer funktion übergeben

[Alex747]

Hallo

ich habe habe eine membervariable vom typ CComboBox

z.b. mit dem namen m_Auswahl

vorrerst will ich mal wissen ob jetzt m_Auswahl ein objekt von CComboBox ist?

Normal schon oder?

ich habe mir eine funktion geschrieben

von der will ich was in die Combobox (m_Auswahl) eintragen

wenn ich aber der funktion m_Auswahl übergeben will dan kommt fehler

"Konvertierung des Parameters 1 von 'class CComboBox' in 'class CComboBox' nicht moeglich"

meine funktion hatt diese signatur

void ElementAusgeben(CComboBox cbox);

und in der funktion will ich was in die Combobox eintragen

cbox.AddString(blabla);

ich kann ja nicht von der funktion aus auf m_Auswahl zugreifen

wäre cool wenn mir jemand helfen könnte

[russkij]

wenn du auf eine member ComboBox mit einer funktion zugreifen willst, und dieser einträge hinzufügen willst, warum machst du nicht die funktion nicht als memberfunktion? dann musst du die combobox nicht mehr der funktion übergeben. wenn es aber eine externe funktion sein muss, dann dürfte die auch nicht auf eine member combobox zugreifen und diese verändern. lösung wäre so in etwa: (grob geschrieben,nicht geprüft, keine syntax geprüft)

myClass

{

 konstruktor

 dekonstruktor

private:

 CComboBox *m_combobox;

void blamethode()

{

CStringList strList; //(oder so ähnlich)

externefuntkion( &strList )

m_comboBox.setStingList(strList); 

//oder wie auch immer man auf die combobox zugreift, ich arbeite mit QT, da ist es etwas anders

}


}

void externefuntkion( &strList )

{

  strList.addString("bla");

  strList.addString("bla");

}


[/PHP]

gruss

[Alex747]

ich glaub ich werds so machen

danke nochamls

[Klotzkopp]

wenn es aber eine externe funktion sein muss, dann dürfte die auch nicht auf eine member combobox zugreifen und diese verändern.

Das ist Unsinn. Der Zugriff einer Funktion auf ihre Parameter hat nichts damit zu tun, ob die Eingangswerte der Funktionsparameter irgendwo Member sind.

@Alex747: Das Problem rührt daher, dass CComboBox keinen Copykonstruktor hat. Der würde aber benötigt: Parameter die "by value" übergeben werden, werden für den Funktionaufruf kopiert. Selbst wenn CComboBox einen Copykonstruktor hätte, würde dir das also nicht helfen, weil du in der Funktion nur die Kopie verändern würdest, das Original bleibt, wie es ist.

Die Lösung ist, den Parameter zu einer Referenz zu machen:

void ElementAusgeben(CComboBox& cbox);

[russkij]

Das ist Unsinn. Der Zugriff einer Funktion auf ihre Parameter hat nichts damit zu tun, ob die Eingangswerte der Funktionsparameter irgendwo Member sind.

ja hab mich wohl falsch ausgedrückt, aber man sollte es so nicht machen oder?

Ich meine, man sollte auf eine Membervariable nur kontrolliert zugreifen lassen, eben über eine Zwischenvariable oder get() set(). ?

gruss

[Klotzkopp]

Ich meine, man sollte auf eine Membervariable nur kontrolliert zugreifen lassen, eben über eine Zwischenvariable oder get() set(). ?

Eine Membervariable aus eine Methode heraus an eine freie Funktion zu übergeben, ist kontrolliert.

Ich halte es im Gegenteil eher für ein Designproblem, wenn man private-Member und dazu jeweils einen public-Getter und Setter hat. Damit gibt nämlich das Interface der Klasse den internen Aufbau wieder, den man ja eigentlich kapseln wollte. Wenn dann noch die Settermethode nichts weiter tut, als den Member zuzuweisen, dann hätte man das sich auch sparen, und den Member public machen können.

Und was das Zwischenobjekt angeht, das du ansprichst: Wenn du nichts weiter tust, als hinterher die Änderungen am Zwischenobjekt ungeprüft in dein eigentliches Objekt zu übernehmen, hast du auch nichts gewonnen, sondern nur zwei unnötige Kopieroperationen hinzugefügt.

Leider sieht man diese Getter-"Lösung" sehr häufig. Ich vermute, das wird durch folgende Herangehensweise verursacht:

- Problem: Ich brauche in Funktion Foo den Member X von Klasse A.

- Member X ist private -> public Getter für X in A erzeugt.

- Nächstes Problem: Ich brauche in Foo ein A, sonst bekomme ich kein X.

Das führt dann zu dem häufigen Fehler, dass einfach in Foo ein neues A-Objekt erstellt wird, und dessen X geholt wird.

Womöglich ist das passende A-Objekt Member einer anderen Klasse, also wird noch ein public Getter in der enthaltenen Klasse erstellt. Und so weiter.

Wenn man statt dessen den benötigten Member einfach an Foo übergibt, statt ihn dort mühselig zu holen, ergibt das IMHO ein viel besseres Design, nicht zuletzt deswegen, weil es ohne zusätzliche Getter auskommt, die das Klasseninterface verschandeln und letztendlich das Interface von der Implementierung abhängig machen. Ein weitere Vorteil: Foo könnte theoretisch auch mit anderen X-Objekten arbeiten, die anderswo liegen. Foo ist nicht an X gebunden, und X auch nicht an seinen Member A.

Um es kurz zu machen: Ich finde den Ansatz von Alex747 viel besser, als die leider so verbreiteten Getter und Setter für jeden Member. Ich habe schon Entwickler gesehen, für die das Anlegen dieser Methoden fast schon ein Reflex geworden ist: wann immer sie einen private Member anlegen, kommen diese Methoden gleich dazu.

Daraus kann ich nur schließen, dass derjenige sich vorher nicht genügend Gedanken über das Interface der Klasse gemacht hat, denn das soll ja eigentlich den internen Aufbau abstrahieren, nicht wiedergeben.

[russkij]

hmm, aus dieser Sicht habe das nocht nicht gesehen.

Aber mit einem get() set() oder Zwischenvariable meinte ich eigentlich auch, dass vor der Zuweisung an die Member erst geprüft wird.

gruss