A co takhle to při výjimce hnedka všechno zrušit? Stejně se nedá spolehnout na to, co zůstane po tom přenosu zpátky, tak proč se vůbec obtěžovat?
To myslíš vážně, nebo si děláš srandu?
A tos neviděl tu alchymii při vkládání prvků na pozici (posun všeho doprava), nebo při mazání jednoho až n prvků z prostřed. Tam si užiješ destruktorů... Já vím, že STL tohle neřeši. Je to jednoduché, stačí výjimky zakázat a tím je problém vyřešen. No není. Možná tak úředně.
No právě protože vím jak těžké je zaručit exception-safety, tak jsem se na to ptal. Ono stačí zakázat výjimky v destruktorech a najednou jsou z neřešitelných problémů problémy obtížné. ![Valím oči! Super! 8)](http://forum.root.cz/Smileys/default/cool.gif)
Ale jde to zaručit, jen to nikdo nechce řešit. Při mazání se výjimka destruktoru řeší tak, že se objekt považuje beztak za zničení, takže rollback se řeší pokračováním operace ničení (a následného přesunu ovšem už v režimu rollback jako stack unwind, takže každý destruktor ví, že už letí výjimka). Totéž pokud dojde k výjimce při konstrukci během vkládání. Opět se to rollbackuje (destruuje již vložené a přesouvá zpět) a to v rámci stack unwindingu.
A pokud by tě zajímalo, jak spustím operaci tak, aby se tvářila jako stack unwind, tak věř mi, je to jednodušší než si myslíš. Napíšu operaci jako třídu, tělo nechám vykonat v destruktoru. Pak jí zkonstruuj a ihned po její konstrukci udělám throw; Destuktor - potažmo vlastní rollback operace se provádí v rámci stack unwind.
Takhle třeba řeším výjimku v destruktoru při ničení celého pole. Destruuje je odzadu a když dojde výjimce, pokračuju v destrukci dopředu ovšem jako stack unwind. Naprosto totožné se totiž děje, když ti při destrukci objektu jeden z memberů vyhodí výjimku.
Sakra, všechno je v tom jazyce popsané. Celý systém je geniálně vymyšlený. Někdy mi přijde, že syntaxi a pravidla dělal jeden tým, zatímco ti méně schopní dostali na starost standardní knihovnu. Podle toho to tak vypadá. Jazyk má geniální logický pravidla, které ta knihovna ani neumí pořádně využít.