Auswahl const-Funktion vs. Non-const-Funktion

[Phoemuex]

Nexus schrieb:

[...] habe ich einen kleinen Container geschrieben. const_iterator ist dabei eine Klasse, die Iteratorfunktionalität bereitstellt, und bei der die Dereferenzierung Const-Zeiger/-Referenzen zurückgibt. Die Klasse iterator ist davon abgeleitet und überschreibt die Dereferenzierungsoperatoren, sodass die referenzierte Objekte veränderbar sind.

Ein iterator ist also ein const_iterator ? (Oder verwendest du keine public-Vererbung?)

Felix

[Shade Of Mine]

iterator und const_iterator sind nicht verwandt. das bedeutet dass man hier doppelten Code schreiben muss, oder aber boost verwenden: http://www.boost.org/doc/libs/1_37_0/libs/iterator/doc/index.html#iterator-facade-and-adaptor

[Nexus]

Ich habe auch schon gehört, dass man das besser nicht tun soll. Aber die Standardbibliothek macht es ja auch so, zumindest in meiner Implementierung (MSVC++ 2008 Express):

template<class _Ty,
	class _Alloc>
	class _Vector_iterator
		: public _Vector_const_iterator<_Ty, _Alloc>
	{	
		// ...
	}

Was ist denn daran so schlecht?

[Nexus]

Würde mich jetzt schon noch interessieren, was gegen die Vererbung spräche, zumal der Standard es bei mir auch so macht. Klar, von der Logik her ist es nicht sehr intuitiv ( iterator ist ein const_iterator ), aber andererseits besitzt ein iterator die gesamte Funktionalität eines const_iterator s und noch darüber hinaus.

[Shade Of Mine]

Du kannst die iteratoren ploetzlich polymorph verwenden.

Die wirkliche Frage sollte eher sein:
warum will ich hier Vererbung haben?

Die Antwort ist: weil es mir schreibarbeit erspart.

Und damit sollte das Thema erledigt sein. Denn "weil es mir schreibarbeit erspart" ist meistens ein guter Hinweis auf einen Designfehler.

Vererbung ist eine enorm starke Bindung die ich nur eingehen will, wenn es mir einen wirklichen Vorteil bringt. Aber die Boost Iterator Facade/Adapter Sachen ersparen mir Kopplung und Schreibarbeit im Vergleich zu der Vererbungsvariante.

Der wirkliche Grund warum viele Standard Libraries iteratoren so implementieren ist weil es einfach und standard konform ist. Aber ist es deshalb gut?

[Tachyon]

Shade Of Mine schrieb:

Der wirkliche Grund warum viele Standard Libraries iteratoren so implementieren ist weil es einfach und standard konform ist. Aber ist es deshalb gut?

Ja, weil es unnötige Codeduplizierung vermeidet, und damit entsprechende Copy and Paste Fehler minimiert.

[volkard]

und ich dachte immer, öffnetliche erblichkeit würde IST EIN bedeuten.
da fällt mir nur http://www.c-plusplus.net/forum/viewtopic-var-t-is-75672-and-highlight-is-bebel.html zu ein.

[Tachyon]

volkard schrieb:

und ich dachte immer, öffnetliche erblichkeit würde IST EIN bedeuten.
da fällt mir nur http://www.c-plusplus.net/forum/viewtopic-var-t-is-75672-and-highlight-is-bebel.html zu ein.

Private Vererbung wäre vielleicht angebrachter.

[Shade Of Mine]

Tachyon schrieb:

Shade Of Mine schrieb:

Der wirkliche Grund warum viele Standard Libraries iteratoren so implementieren ist weil es einfach und standard konform ist. Aber ist es deshalb gut?

Ja, weil es unnötige Codeduplizierung vermeidet, und damit entsprechende Copy and Paste Fehler minimiert.

Und die Nachteile ignorieren wir einfach?

natuerlich ist es bequem. aber bequem ist meistens falsch.

schau dir bitte boost iterator facade/adapter an. du schreibst einen bruchteil von code den du mit der vererbungsvariante brauchst und bist deutlich fehlerfreier.

wenn du privat vererbst umgehst du zwar die probleme hast aber wieder viel schreibarbeit. und dann wuerde ich sowieso zu layering raten, du hast ein iterator objekt dass alle operationen anbietet und jeweils eine facade fuer iterator und const_iterator drueber...

aber die richtige wahl ist dennoch boost...

[Nexus]

volkard schrieb:

da fällt mir nur http://www.c-plusplus.net/forum/viewtopic-var-t-is-75672-and-highlight-is-bebel.html zu ein.

Nettes Geschichtlein.

Ich werde mir wahrscheinlich mal Boost.Iterator anschauen. Danke für die Antworten!

[jtsfds133]

mammamia;