Question

Selon boost :: documentation tuple , l'accès à un seul élément d'un tuple a les mêmes performances que l'accès à une variable de membre. Par exemple, compte tenu de la déclaration suivante:

tuple<A, B, C> t1(A(), B(), C());
struct T { A a; B b; C c; }
T t2;

Ces deux déclarations doivent avoir le même (ou avec une différence négligeable) la performance:

t1.get<2>();
t2.c;

J'ai regardé dans les sources de boost :: tuple et, si je les comprends bien (je ne suis pas sûr que je l'ai fait), la fonction get<N> effectue effectivement cette action:

C get<2>(tuple<A, B, C>& t)
{
    return t.tail.tail.head;
    //Generally:  return t.tail. <<N times>> .head;
}

Ceci est plus semblable à une consultation dans une liste, d'un accès direct, et, pour autant que j'undestand, a O (N) complexité au lieu de O (1), qui est attendu d'un accès membre. De mes expériences passées avec coup de pouce, je suppose que je l'ai eu tort; mais quel est mon erreur? Comment get vraiment?

Était-ce utile?

La solution

Vous avez raison à propos de la liste comme la performance. Cependant, il peut être résolu à la compilation et revient donc vers le bas pour O (1) lors de l'exécution. (Étant donné un compilateur suffisamment bonne optimisation.)

Autres conseils

Rappelez-vous, en C ++, l'opérateur point n'est pas une déférence de pointeur, il est un calcul de décalage direct. La réponse générale est oui, i1.i2.i3.in pour tout n est calculable de fonctionnement à temps constant au moment de la compilation.

Si vous voulez apprendre un peu plus sur le compilateur pour cela sans internals creuser très profond, regardez LLVM getelementptr

scroll top