QVectores mayormente análogo a std::vector, como se puede adivinar por el nombre. QListestá más cerca boost::ptr_deque, a pesar de la aparente asociación con std::list. No almacena objetos directamente, sino que almacena punteros a ellos. Obtiene todos los beneficios de las inserciones rápidas en ambos extremos, y las reasignaciones implican barajar punteros en lugar de constructores de copia, pero pierde la localidad espacial de un std::dequeo real std::vectory gana muchas asignaciones de montón. Tiene alguna toma de decisiones para evitar las asignaciones de montón para objetos pequeños, recuperando la localidad espacial, pero por lo que entiendo, solo se aplica a cosas más pequeñas que un int.
QLinkedListes análogo std::listy tiene todas sus desventajas. En términos generales, esta debería ser su última elección de contenedor.
La biblioteca QT favorece en gran medida el uso de QListobjetos, por lo que favorecerlos en su propio código a veces puede evitar un tedio innecesario. El uso adicional del montón y el posicionamiento aleatorio de los datos reales pueden, en teoría, dañar en algunas circunstancias, pero a menudo es imperceptible. Por lo tanto, sugeriría usar QListhasta que el perfil sugiera cambiar a un QVector. Si espera que la asignación contigua sea importante [lea: está interactuando con un código que espera un en T[]lugar de un QList<T>], eso también puede ser una razón para comenzar desde el principio QVector.
Si está preguntando sobre contenedores en general y solo utilizó los documentos de QT como referencia, entonces la información anterior es menos útil.
An std::vectores una matriz cuyo tamaño puede cambiar. Todos los elementos se almacenan uno al lado del otro y puede acceder a elementos individuales rápidamente. La desventaja es que las inserciones solo son eficientes en un extremo. Si pones algo en el medio, o al principio, tienes que copiar los otros objetos para hacer espacio. En notación de oh grande, la inserción al final es O (1), la inserción en cualquier otro lugar es O (N) y el acceso aleatorio es O (1).
An std::dequees similar, pero no garantiza que los objetos se almacenen uno al lado del otro y permite que la inserción en ambos extremos sea O (1). También requiere que se asignen porciones más pequeñas de memoria a la vez, lo que a veces puede ser importante. El acceso aleatorio es O (1) y la inserción en el medio es O (N), lo mismo que para a vector. La localidad espacial es peor que std::vector, pero los objetos tienden a agruparse, por lo que obtienes algunos beneficios.
An std::listes una lista vinculada. Requiere la mayor sobrecarga de memoria de los tres contenedores secuenciales estándar, pero ofrece una inserción rápida en cualquier lugar ... siempre que sepa de antemano dónde debe insertar. No ofrece acceso aleatorio a elementos individuales, por lo que debe iterar en O (N). Pero una vez allí, la inserción real es O (1). El mayor beneficio std::listes que puede unirlos rápidamente ... si mueve un rango completo de valores a un valor diferente std::list, toda la operación es O (1). También es mucho más difícil invalidar referencias en la lista, lo que a veces puede ser importante.
Como regla general, prefiero std::dequehacerlo std::vector, a menos que necesite poder pasar los datos a una biblioteca que espera una matriz sin procesar. std::vectorse garantiza contiguo, por lo que &v[0]funciona para este propósito. No recuerdo la última vez que usé un std::list, pero fue casi seguro porque necesitaba una garantía más fuerte para que las referencias siguieran siendo válidas.