195 votes

Quels langages C++ sont déconseillés dans C ++11

Avec la nouvelle norme, il existe de nouvelles façons de faire les choses et beaucoup sont plus agréable que les anciennes méthodes, mais la vieille manière est toujours très bien. Il est également clair que la nouvelle norme ne désapprouve officiellement beaucoup, pour des raisons de compatibilité descendante. La question qui demeure est donc :

Quelles anciennes méthodes de codage sont certainement inférieures à C ++11 styles, et que pouvons-nous maintenant faire à la place ?

Pour répondre à cela, vous pouvez ignorer les choses évidentes comme « utiliser des variables d’auto ».

175voto

Sumant Points 2294
  1. Finale de la Classe: C++11 présente l' final rédacteur de devis pour éviter la dérivation de classe
  2. C++11 lambdas de réduire considérablement la nécessité pour le nom de fonction de l'objet (foncteur) des classes.
  3. Constructeur de déplacement: La magie des façons de std::auto_ptr œuvres ne sont plus nécessaires en raison de soutien de première classe pour les références rvalue.
  4. Coffre-fort bool: Cela a été mentionné plus tôt. Explicite les opérateurs du C++11 obvier à cette très common C++03 idiome.
  5. Shrink-to-fit: Beaucoup de C++11 STL prévoit shrink_to_fit() de la fonction membre, ce qui devrait éliminer le besoin de permuter avec un temporaire.
  6. Temporaire de la Classe de Base: Quelques vieilles bibliothèques C++ utiliser ce processus complexe de l'idiome. Avec la sémantique de déplacement, il n'est plus nécessaire.
  7. Type de Coffre-fort d'Énumérations les Énumérations sont très sûrs en C++11.
  8. Interdisant l'allocation de segment: Le "= supprimer" syntaxe est une manière beaucoup plus directe de dire qu'une fonctionnalité particulière est explicitement refusé. Ceci est applicable à la prévention de l'allocation de segment (c, =supprimer pour les membres de l'opérateur de nouvelles), la prévention de copies, de cession, etc.
  9. basé sur un modèle typedef: Alias templates en C++11 de réduire la nécessité pour de simples basées sur des modèles de typedefs. Cependant, de type complexe générateurs encore besoin des fonctions de meta.
  10. Certaines numérique au moment de la compilation des calculs, tels que fibonacci peut être facilement remplacé utilisation Généralisée des expressions constantes
  11. result_of: utilisation du modèle de classe result_of doit être remplacé par decltype. Je pense que result_of utilise decltype quand il est disponible.
  12. -Membre de la classe des initialiseurs d' épargner de la saisie pour défaut d'initialisation de non-membres statiques avec des valeurs par défaut.
  13. En C++11 code NULL doit être redéfini comme nullptr mais voir STL parler pour savoir pourquoi ils ont décidé contre elle.
  14. L'Expression du Modèle de fanatiques sont ravis d'avoir de la fuite type de retour de la fonction de syntaxe en C++11. Pas plus de 30 lignes, des types de retour!

Je pense que je vais m'arrêter là!

66voto

Howard Hinnant Points 59526

À un moment donné, on a soutenu qu’on devrait retourner en `` valeur au lieu de simplement en valeur :

Cela a été pour la plupart inoffensif dans C ++98/03 et peut avoir même pris quelques bugs qui ressemblait à :

Mais le retour de `` est contre-indiqué dans C ++11 car elle inhibe la sémantique move :

Alors détendez-vous et code :

61voto

Howard Hinnant Points 59526

Dès que vous le pouvez abandonner 0 et NULL en faveur de l' nullptr,!

Dans le code non générique l'utilisation de l' 0 ou NULL n'est pas une grosse affaire. Mais dès que vous commencez à passer autour de pointeur null constantes dans le code général de la situation change rapidement. Lorsque vous passez 0 d'un template<class T> func(T) T obtient en déduit que l' int et non pas comme un pointeur null constante. Et il ne peut pas être convertie en un pointeur null constante par la suite. Cette cascade dans un bourbier de problèmes qui n'existent tout simplement pas si l'univers utilisé seulement nullptr.

C++11 ne pas déprécier 0 et NULL comme pointeur null constantes. Mais vous devriez le code comme si elle le faisait.

38voto

KennyTM Points 232647

Bool Safe idiome → `` .

Copie privée constructeurs (boost::noncopyable) →``

simulant la classe finale avec privé destructeur et héritage virtuel``

24voto

Klaim Points 24511

L'une des choses qui vous font juste d'éviter d'écrire des algorithmes de base en C++11, c'est la disponibilité des lambdas en combinaison avec les algorithmes fournis par la bibliothèque standard.

Je suis l'aide de ces maintenant et c'est incroyable à quelle fréquence vous venez de dire ce que vous voulez faire en utilisant count_if(), for_each() ou d'autres algorithmes plutôt que d'avoir à écrire de la merde boucles de nouveau.

Une fois que vous êtes à l'aide de C++11 compilateur C++11 de la bibliothèque standard, vous n'avez aucune bonne excuse pour ne plus utiliser des algorithmes standard pour construire le votre. Lambda juste le tuer.

Pourquoi?

Dans la pratique (après avoir utilisé ce moyen de l'écriture d'algorithmes moi-même), il se sent beaucoup plus facile à lire quelque chose qui est construit avec des termes simples, signifie ce qui est le fait que certaines boucles que vous avez à uncrypt de connaître le sens. Cela dit, faire lambda arguments automatiquement déduit aiderait beaucoup de syntaxe plus facilement comparable à un cru de boucle.

Fondamentalement, la lecture des algorithmes avec des algorithmes standard sont de loin plus facile que les mots de cacher les détails d'implémentation de la boucle.

Je devine seulement de niveau supérieur, les algorithmes d'être pensé, maintenant que nous avons niveau inférieur des algorithmes pour construire sur.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X