Devrais-je rendre mes fonctions aussi générales que possible?

Question

template<class T> 
void swap(T &a, T &b) 
{ 
    T t; 

    t = a; 
    a = b; 
    b = t; 
} 

remplacer

void swap(int &a, int &b) 
{ 
    int t; 

    t = a; 
    a = b; 
    b = t; 
} 

Ceci est l'exemple le plus simple que je pourrais trouver, mais il devrait y avoir beaucoup d'autres functions.Should compliquées que je fais toutes les méthodes que j'écris si possible basé sur un modèle?

Des inconvénients à le faire?

merci.

Answer 1

La généricité a l'avantage d'être réutilisable. Cependant, écrire des choses génériques, seulement si:

1. Il ne prend pas beaucoup plus de temps pour le faire, que de le faire non générique
2. Il ne complique pas le code plus d'une solution non-générique
3. vous savez bénéficier plus tard

Cependant, connaître votre bibliothèque standard. Le cas que vous avez présenté est déjà en STL en tant que std::swap. De plus, n'oubliez pas que lors de l'écriture générique à l'aide de modèles, vous pouvez optimiser des cas spéciaux en utilisant la spécialisation de modèle. Cependant, toujours à quand il est nécessaire pour la performance, pas comme vous l'écrivez.

Notez également que vous avez ici la question des performances d'exécution et de compilation. Les solutions basées sur des modèles augmentent le temps de compilation. Les solutions en ligne peuvent mais ne doivent pas diminuer l'exécution.

`Cause " L'optimisation prématurée et la généricité sont la racine de tout mal ". Et vous pouvez me citer sur ce -_-.

Answer 2

Faites-les aussi génériques que possible. Si c'est vraiment trivial (comme dans l'exemple ci-dessus) alors cela ne prend pas de travail supplémentaire, et pourrait vous épargner du travail dans le futur

Answer 3

Il y a des inconvénients à utiliser des modèles tout le temps. Il (peut) augmenter considérablement le temps de compilation de votre programme et peut rendre les erreurs de compilation plus difficiles à comprendre.

Comme dit taldor, ne rendez pas vos fonctions plus génériques que nécessaire.

Answer 4

Le code réutilisable est réutilisable uniquement si vous le réutilisez réellement. écris donc la fonction naturellement en première instance. Si un peu plus tard vous tombez sur une situation où le code pourrait être réutilisé avec un petit tweak, revenez le refactoriser. C'est à l'étape du refactoring que vous devriez envisager d'écrire des fonctions de template.

Answer 5

La réponse la plus simple à votre question est ce que beaucoup de gens plus intelligents que moi-même avons été dit pendant des années:

Ne jamais écrire plus que le minimum que vous pouvez sortir avec.

Answer 6

Vous pouvez consulter les paramètres de la fonction et la façon dont ils sont utilisés.Si toutes les opérations sont effectuées par des opérateurs surchargés, la fonction peut être très générique et être un bon candidat pour devenir un modèle. Dans le cas contraire, la présence d'appels de types et de fonctions de classe très spécialisés peut rendre la réutilisation générique très problématique et toute flexibilité éventuelle devrait plutôt être réalisée grâce au polymorphisme.

Answer 7

La première fois que vous écrivez vous ne devriez pas échanger

La deuxième fois, il pourrait être tentant, mais parfois vous pouvez sortir sans faire tout ça un gâchis

La troisième fois, il devrait être clair que vous devez. Cependant, selon le nombre de places que vous avez utilisé un et deux, il peut prendre beaucoup de temps si la deuxième fois devrait être une bonne décision

Answer 8

Quelques réflexions:

1. Connaître le TSL. Il y a déjà std::swap. Au lieu de passer votre temps à tout rendre aussi générique que possible, passez votre temps à vous familiariser avec le STL.

2. Ne le faites pas jusqu'à ce que vous en ayez besoin: "Always implement things when you actually need them, never when you just foresee that you need them."---Ron Jeffries. Si vous ne réutilisez pas réellement le code, vous n'avez pas écrit de code réutilisable, vous avez écrit du code inutile. Un code inutile est coûteux à mettre au point, coûteux à tester et coûteux à entretenir. Ne pas oublier opportunity cost! Gardez les choses simples: «Rendez tout aussi simple que possible, mais pas plus simple.» --- Albert Einstein. C'est KISS.