NemesisRD.core 2.10.06.8 - Reescritura de nemesis::SortedVector
Cisco
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!
Eduardo Ramos Testillano
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:
Cisco
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.
Eduardo Ramos Testillano
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