cons_iterator -> iterator und retour

TheBigW

Ich hab mir 'nen Copy - Konstruktor gebastelt, wo ich meine std::list copiere:

ImageIO::ImageIO( const ImageIO& theIo )
{
	ImageIO* pIo = (ImageIO*)&theIo;//Uaahhh
	m_lImageLoaderObj.insert( m_lImageLoaderObj.begin(), pIo->m_lImageLoaderObj.begin(), pIo->m_lImageLoaderObj.end() );	
}

Diesen unschönen Cast, würde ich gerne vermeiden, aber theIo.m_lImageLoaderObj.begin() lieferrt mir ja einen const_iterator, mit dem insert ja nichts anfangen kann.
Ich hatte auch noch einen schönen Ansatz aus Effektive STL mittels:

advance( Iter, distance<const_iter>( Iter, ConstIter ) ).

bringt mir ja aber nichts, weil ich Iter ja nie irgendeinem const_iterator aus pIo->m_lImageLoaderObj zugewiesen bekomme.

Muß ich mit dem cast leben? ->so schlimm ist er ja eigentlich gar nicht, oder?

Shlo

Warum nicht gleich:

ImageIO::ImageIO(ImageIO& theIo )
{ 
    //...
}

BTW, es würde auch folgendes reichen:

ImageIO::ImageIO(const ImageIO& theIo )
: m_lImageLoaderObj(theIo.m_lImageLoaderObj)
{ 
    //...
}

Wenn das Kopieren, die einzige Operation die du im ctor durchführst ist, könnte man den copy-ctor ganz weglassen.

TheBigW

stimmt schon, ging mir eigentlich in dem Fall wirklich nur um die Spielerei: angenommen, die Definition würde so wirklich schon feststehen und ich dürfte nichts mehr ändern :).

Wenn das Kopieren, die einzige Operation die du im ctor durchführst ist, könnte man den copy-ctor ganz weglassen.

Nene, da passieren dann schon noch ein paar andere Sachen.

HumeSikkins

TheBigW schrieb:

Muß ich mit dem cast leben? ->so schlimm ist er ja eigentlich gar nicht, oder?

Also erstmal ist dieser C-Style-Cast eine Katastrophe. Du willst ein const wegcasten, also sag das auch eindeutig:

ImageIO* pIo = const_cast<ImageIO*>(&theIo);

Desweiteren verstehe ich dein Problem nicht. std::list::insert ist ein Membertemplate parametrisiert auf einen Iterator-Typ. D.h. du kannst als zweiten und dritten Parameter auch ohne weiteres einen list<T>::const_iterator
verwenden.

Selbst wenn du die veraltete Dinkumware-Implementation des VC 6.0 verwenden solltes sehe ich kein Problem. Hier wurde das Membertemplate durch eine Methode ersetzt, die ein const_iterator erwartet.

Zur Not kannst du auch einfach std::copy verwenden.

Shade Of Mine

warum verlangt insert einen nicht const iterator?? bzw. warum sind begin() und end() nicht auch const??

Ich verstehe das Problem nicht.

TheBigW

@ Hume:

Danke - Asche auf mein Haupt const_cast hab ich noch nie benutzt.

Desweiteren verstehe ich dein Problem nicht. std::list::insert ist ein Membertemplate parametrisiert auf einen Iterator-Typ. D.h. du kannst als zweiten und dritten Parameter auch ohne weiteres einen list<T>::const_iterator
verwenden.

Sorry, tut er auch -> hatte vorher eine Copy Funktion mittels Schleife über alle iteratoren -> da hat er natürlich gemeckert (hatte mit dem insert natürlich nichts zu tun).

TheBigW

Zum Abschluß noch ein mal ein (hoffentlich) wirkliches Problem:

Ich habe in einem kleinen Projekt auf eine bisschen Quellcode aufgesetzt wo folgendes gemacht wurde:

const_iterator GetIter(....)const{...}
iterator GetIter(....){...}

Diese Überladung hat der VC6 problemlos geschluckt. Im VC7 hat er damit aber Probleme -> welcher von den beiden hat nunn recht?

otze

wenn die "..." fehlerfrei sind, müsste das eigentlich jeder compiler so nehmen

TheBigW

Was kann an ... schon falsch sein

Ne, da steht wirklich nur:

const_iterator GetIter(void)const
{
   return myVector.begin();
}

iterator GetIter(void)
{
   return myVector.begin();
}

aber der VC7 scheint das nicht auflösen zu können:

const_iterator it = GetIter();

bringt einen Konvertierungsfehler von const_iterator auf iterator. Folglich konnte er es nicht auflösen. Die iteratoren sind natürlich typedefs, aber das sollte ja wohl egal sein.
Hab jetzt die Funktion für const in GetIterConst(..) umbenamst und schon gehts - merkwürdig.

cons_iterator -&gt; iterator und retour

cons_iterator -> iterator und retour