ciertamente el truco de la lista auxiliar no es muy elegante, pero funciona.
No sab a que te ricamente "se pod a borrar un iterador dentro del propio
bucle que lo recorre", desde que me fall como una escopeta de feria
pense que no. Adem s es l gico que no funcione puesto que al borrarlo se
pierde la informaci n de la lista enlazada para el iter++ del bucle.
Lo que no he probado, y seguramente s funcione, y s es elegante, es
usar el while, en vez del for, almacenando el iterador que cumple la
condicion, aplicando el operator++ y luego borrando aquel (a posteriori).
Bueno, pues gracias por el SortedVector, ahora s parece m s til que
cuando se basaba en un mapa.
un saludo
El 29/10/2010 8:46, Cisco escribi :
> Ya, pero a nivel de core de plataforma creo que no se debe montar
> semejante l o o por lo menos se deben buscar formas de evitarlo.
> En la versi n v2.10.12 se ha incluido un paquete de contenedores,
> entre otros se han metido tablas Hash que tienen una eficiencia
> te rica de O(1) mientras que un std::map es de O(log N), pero lo mejor
> es que en el d a a d a ofrecen muchas ventajas, entre otras puedes
> borrar un elemento mientras recorres la lista y no te tienes que
> preocupar de nada, es ese aspecto son tan flexibles como los vectores.
> As que los contextos de temporizaci n es muy posible que se
> reescriban aprovechando las ventajas de estos nuevos contenedores,
> porque uno de los mayores problemas que hubo que solucionar fu evitar
> que borraran/crearan entradas en el Quamtum de tiempo que se estaba
> procesando.
> Un saludo.
> On Oct 28, 5:28 pm, Eduardo Ramos Testillano<era...@tid.es> wrote:
>> con el borrado de iteradores en mapas ya tuve yo problemas. Es debido a
>> que al meter el erase dentro del bucle,
>> se modifican los extremos y da lugar a "inestabilidad". Para evitarlo
>> hay que generar una lista de iteradores que cumplen
>> la condicion y luego aplicarles el erase. Pero nunca dentro de un bucle.
>> Desde luego es bastante inc modo pero funciona (lo uso para borrar
>> contextos expirados (esa ser a la condicion) en ciertos procesos).
>> un saludo
>> El 28/10/2010 15:22, Cisco escribi :
>>> Modifica el nemesis::SortedVector para basar su funcionamiento en un
>>> std::vector en vez de en un std::map.
>>> No es tan r pido como la primera versi n pero tiene la ventaja de que
>>> permite claves repetidas.
>>> Adem s tiene la ventaja de que se pueden borrar elementos mientras
>>> iteramos por el contenido de los mismos. En teor a en los std::map
>>> tambi n se puede, pero en la pr ctica se ha comprobado que el
>>> siguiente c digo daba problemas:
>>> for (iterator ii = zzzz.begin (); ii != zzzz.end (); ii ++) {
>>> if (<alguna condicion>) {
>>> zzz.erase (ii);
>>> }
>>> }
>>> Con la nueva implementaci n se deber a hacer:
>>> for (iterator ii = zzzz.begin (); ii != zzzz.end (); /* Observar que
>>> ii se incrementa de forma condicional */ ) {
>>> if (<alguna condicion>) {
>>> ii = zzz.erase (ii);
>>> continue;
>>> }
>>> ii ++;
>>> }
>>> ./hdrs/nemesis.SortedVector.h | Locally Modified | 1.26.6.1.2.1
>>> ./internal.db/core.sccs.cc | Locally Modified | 1.124.2.25.2.8.2.8
>>> ./what_new/2.10.07.08.version | Locally Added | New file!
