Zugriff auf einzelne Elemente eines Container-Members

[oo_O]

brotbernd schrieb:

Eine GetWorker ist schon ok. Benutze size_t pos als Argument und den Range check bekommst du durch return m_Workers.at(pos);
Und wie du vielleicht schon mitbekommen hast, sagt kein Schwein mehr CWorker sondern Worker. Aber das ist ja eher Geschmackssache.

Wenn man langsamen Code will, OK.

[Nexus]

Dieser tolle Range-Check bei at() , wie oft braucht man den tatsächlich? Wie viel öfter missbraucht man ihn, um Logikfehler mit catch statt assert zu fangen?

[brotbernd]

Ich habe nicht gesagt, dass er at() statt operator[] verwenden soll. Es war nur ein Hinweis, dass er die Überprüfung nicht selber schreiben muss (was er andeutete).

Und diese Anwendung klingt nun wirklich nicht so, als sei eine GetWorker(size_t) ein Flaschenhals. Langsamer code...

[Simon2]

brotbernd schrieb:

Simon2 schrieb:

brotbernd schrieb:

...
Änderst du vector<Worker> in set<Worker> musst du die ganze Welt ändern, ...

Keineswegs. Ich kann durchaus weiterhin einen vector rausgeben - auch wenn ich intern die Daten anders verwalte.
Das wird mit einem non-const-Ref-vector natürlich "schwieriger" ... aber wenn man sich dagegen absichern will, nimmt man eben die "getter/setter"-Variante oder einen Container, der das Fachobjekt über Änderungen informiert.

Was heißt hier keineswegs. ...

Keineswegs eben.

"Die Welt" muss nichts ändern, wenn ich weiterhin lediglich einen vector rausgebe (und die Daten intern in einem set ablege).
Aber wie schon (mehrfach) gesagt: Da unterscheidet sich vector nicht von anderen Datentypen, die man (als Bestandteil der Schnittstelle) "mit der Welt teilt". Will ich eine Schnittstellenkonstanz, muss ich entsprechend die Daten auf dem Weg in die Welt gehend oder aus ihr kommend "aufbereiten".

brotbernd schrieb:

...Für Strings interessiert man sich i.d.R. im ganzen. Für vectoren nicht (immer). Da interessieren mich meistens eher die einzelnen Elemente.

hmmm, erlebe ich anders. Gerade deine "Iteratorlogik" spiegelt doch eher den "Collectionaspekt" wider (Zugriff auf einzelne Elemente ist damit umständlich).

Aber vielleicht habe ich den Schwerpunkt meiner Aussagen noch nicht ausreichend deutlich gemacht: Die Idee, interne Verwaltungsstrukturen direkt nach außen zu geben, halte ich für nicht besonders sinnvoll - egal ob über Iterator, eine Indexzugrifffunktion oder eine direkte Referenz auf den internen Container.
Aber wenn man der Welt eine Menge zu Verfügung stellt, sollte man das IMHO am Besten auch genauso tun: Als Menge! ... und mit einem dafür geeigneten Datentyp.

Und mir scheint eben an diesem Punkt bei Vielen die "Tuning-Paranoia" zuzuschlagen, die einem einflüstert "Warte mal! Du hast die Daten doch sowieso intern schon in einem vector ... den kannst du doch einfach so rausgeben (direkt oder via (evtl. tw.) "Schittstellenweiterleitung") - ist bestimmt am schnellsten (programmiert und Laufzeit)!"
... um sich dann um den selbsteingebauten Kapselungsbruch und/oder Flexibilitätseinbuße zu ärgern.

Gruß,

Simon2.