2009-11-24 15 views
0

disons que j'ai 3 fonctions dans une classe:externe vs liaison interne et la performance

class Foo { 
    inline void FooInline() { /* bla bla */ } 
    static void fooStatic(); 
    void foo(); 
}; 

que je comprends les deux derniers ont une liaison externe alors que la première ont interne.

Je veux savoir quelle fonction sera la plus rapide à appeler, et quel est le compromis.

merci

+1

Dans le sujet de votre question, vous faites référence au couplage, alors que la question réelle semble concerner la performance. Ces deux concepts sont pratiquement indépendants. Alors, qu'est-ce que vous voulez savoir sur: le lien ou la performance? – AnT

Répondre

5

Non, tous les trois ont une liaison externe. Les fonctions membres d'une classe non locale ont toujours un lien externe en C++. De plus, inline n'a aucun effet sur la liaison, même s'il s'agit d'une fonction non-membre.

La liaison n'a aucun effet sur l'efficacité. Inline pourrait avoir, mais cela dépend de trop de variables.

+0

Pas vrai.inline rend implicitement la fonction static, et static donne la fonction linkage interne. – Tomas

+3

@Tomas - la norme C++ dit spécifiquement "Le mot-clé inline n'a aucun effet sur le lien d'une fonction" –

+0

@ Michael Burr: d'ici: http://msdn.microsoft.com/en-us/library/z8y1yy88(VS .71) .aspx Les fonctions déclarées comme inline, et qui ne sont pas des fonctions membres de classe, ont une liaison interne sauf indication contraire. Vous ne savez pas si Microsoft est spécifique. – BostonLogan

0

inline n'a pas de "linkage" par exemple, il habituellement (bien que le compilateur ne doit pas se conformer) met juste le code littéralement, uhh, inline.

Vous voyez une liaison interne avec des espaces de noms anonymes et des fonctions statiques (indépendantes de la classe), par ex.

namespace 
{ 
    void foo() { ... } 
} 

Ou:

static void foo() { ... } 

lien interne signifie que le compilateur peut faire une optimisation supplémentaire (car il sait exactement comment la fonction est utilisée) et ne doit pas créer un symbole exporté, ce qui signifie moins de relocations au démarrage (ce qui signifie des démarrages plus rapides - bien que les lieurs modernes fassent une résolution de symbole paresseuse ...)

+0

les fonctions en ligne ne seront jamais exportées; donc en ligne implique un lien interne. – Tomas

+2

@Tomas: Incorrect. «inline» n'implique pas de liaison interne. – AnT

+0

@scotchi: Pas vrai. Toutes les fonctions du programme C++ ont un lien externe par défaut, l'ajout en ligne ne change rien à la liaison. De même, formellement, une fonction déclarée dans un espace de noms anonyme a toujours un lien externe, même si vous ne pouvez pas le "nommer" à partir d'autres unités de traduction. – AnT

-1

Le second a une liaison interne puisque vous l'avez déclaré statique. Il ne peut être référencé que dans la même unité de traduction.

+3

L'OP indique explicitement que la fonction est membre d'une classe. 'static' n'a aucun effet sur la liaison des membres de la classe. – AnT

+0

Bon point - lire le message original trop rapidement et raté cela. Hélas! –

1

juste pour être clair.

class fooClass 
{ 
    inline void fooInline() { /*blah blah*/ } 
    static void fooStatic() { /*blah blah*/ } 
    void foo() { /*blah blah*/ } 
}; 

Comme noté ailleurs. inline n'a aucun effet sur la liaison. Aussi static utilisé comme ci-dessus dans une déclaration/définition de méthode ne porte aucune sémantique de liaison. static est malheureusement un mot-clé trop utilisé. Il affecte la liaison lorsqu'il est utilisé sur des variables/fonctions globales/d'espace de noms. Il a une signification totalement différente lorsqu'il est appliqué aux méthodes de classe. En ce qui concerne votre question, ils ont tous un lien externe. Ils ont tous la même performance lorsqu'ils sont appelés. La ligne Might ont et l'avantage IF les deux autres fonctions sont définies dans un fichier cpp au lieu de la classe ET le compilateur décide qu'il sera plus rapide à inline appels à fooInline. fooInline n'aura aucun avantage dans le fichier source où foo et fooStatic sont définis.

Tout cela ressemble à une optimisation prématurée. Il y a d'autres problèmes qui valent la peine d'être résolus et qui rendront votre code beaucoup plus rapide.