pairs - vector c++

estructura con 2 celdas vs std:: par?

Question

Posible duplicado:
¿Cuál es la diferencia entre usar una estructura con dos campos y un par?

Queridos todos,

Tengo una pequeña pregunta sobre pares y estructura. ¿Hay alguna ventaja de usar un std :: pair en lugar de una estructura con dos celdas? He usado pares por un tiempo, pero el problema principal es la legibilidad: si desea representar, por ejemplo, un dúplex (int "label", double "value") puede usar uno:

typedef std::pair<int,double> myElem;

o un

typedef struct {
    int label;
    double value;
} myElem;

El código se vuelve más legible si sus declaraciones tienen un sentido "semántico" (siempre sabrá qué es x.label. Ese no es el caso con x.first).

Sin embargo, supongo que hay una ventaja al usar par. ¿Es más performante o algo más?

Answer 1

Sin embargo, supongo que hay una ventaja al usar par. ¿Es más performante o algo más?

Lo dudo, un std::pair instanciado es solo una struct , después de todo. std::pair viene con operator< definido, sin embargo. Pero eso no debería ser demasiado difícil de hacer por ti mismo para una struct con solo dos miembros.

Por lo general, hago lo que usted razonó: una struct con nombres de miembros dedicados es más fácil de leer que el first y el second .

Answer 2

Con un std :: pair, puede utilizar los funtores de la STL como select1st o select2nd. Asimismo, le permite utilizar otras funciones genéricas con su par, como el operador <y otros. Es cierto que con el advenimiento de boost / tr1, se podría lograr el mismo efecto al usar bind.

Sin embargo, tu punto sobre la legibilidad es muy cierto.

Answer 3

En términos de rendimiento: es poco probable que cambie algo, solo estás cubierto de azúcar.

En términos de facilidad de uso, prefiero usar una estructura personalizada, que se puede declarar de esta manera (por cierto):

struct MyElement
{
  int label;
  double value;
};

Soy un firme defensor de la tipificación fuerte, y prefiero una estructura "real" (y, mejor aún, clase) que una tupla ad hoc cuando es más que una cosa fugaz.

Principalmente porque:

• Como notaste first y second no tienen mucho significado
• No puede agregar métodos / otros campos a un std::pair
• No puede agregar invariantes de clase a un std::pair

En general, realmente creo que el mantenimiento se beneficia del uso de una estructura dedicada personalizada que es una tupla de talla única para todos.

Answer 4

Su principal ventaja es que es genérico. Por ejemplo, cuando recuperas algo de un std::map , obtienes la clave y el valor asociado como el primer y segundo elemento en un std::pair .

Del mismo modo, cuando usa std::equal_range para encontrar un conjunto de valores iguales en una colección, obtiene los iteradores al principio y al final del rango como el primer y segundo elemento en un std::pair .

Es difícil imaginar etiquetas significativas que se apliquen a ambos, por lo que se conformaron con una pareja que no significa mucho, pero al menos no son engañosas. Usar ''key'' y ''data'' funcionaría para std::map , pero sería engañoso para std::equal_range (y si cambia a algo como lower_bound y upper_bound para hacerlos más significativos para std::equal_range , sería igualmente incorrecto para los artículos en std::map ).

Answer 5

Un pair se implementa como una struct plantilla. Le proporciona una taquigrafía para crear un par (generalmente heterogéneo). Además, hay algunas restricciones en los tipos que puedes usar con un pair :

Requisitos de tipo

T1 y T2 deben ser modelos de Asignables. Las operaciones adicionales tienen requisitos adicionales. El constructor predeterminado del par solo se puede usar si T1 y T2 son DefaultConstructible, operator == solo se puede usar si T1 y T2 son EqualityComparable, y operator <solo se pueden usar si T1 y T2 son LessThanComparable.

(de SGI STL std::pair documentación de std::pair )

Definir su propio POD puede tener sentido si los tipos no siguen ninguna de estas restricciones o si no le importan.

Finalmente, supongo que es una cuestión de elección personal / estilo de codificación.