11
votes

Utiliser ou ne pas utiliser de fonctionnalités C ++ 0x

Duplicaté possible:

Comment utilisez-vous C ++ 0x aujourd'hui?

Je travaille avec une équipe sur un système assez nouveau. Nous parlons de migrer vers MSVC 2010 et nous avons déjà migré vers GCC 4.5. Ce sont les seuls compilateurs que nous utilisons et nous n'avons aucune intention de porter notre code à différents compilateurs à tout moment.

J'ai suggéré qu'après nous le faisons, nous commençons à tirer parti de certaines des fonctionnalités C ++ 0X déjà fournies comme Auto. Mon collègue a suggéré à ce sujet, proposant d'attendre "jusqu'à ce que c ++ 0x devienne standard". Je dois être en désaccord, mais je peux voir l'appel dans la façon dont il l'a libellé. Néanmoins, je ne peux pas m'empêcher de penser que ce contre-argument est davantage de peur et de trépidation de l'apprentissage C ++ 0x qu'une véritable préoccupation de la normalisation.

Compte tenu de la nouvelle état du système, je souhaite que nous profitiions à la nouvelle technologie disponible. Juste Auto, par exemple, rendrait notre vie quotidienne plus facile (écrivant simplement Itératrice - basé sur des boucles jusqu'à ce que les boucles à pied varient, par exemple.

je me trompe de penser cela? Ce n'est pas comme si je propose que nous modifions radicalement notre base de code en herbe, mais commençons simplement à utiliser des fonctionnalités C ++ 0X où pratiques. Nous savons quels compilateurs nous utilisons et ne disposent pas de plans immédiats de port (si nous avons déjà porté la base de code, alors des compilateurs de C ++ seront également disponibles avec des fonctionnalités C ++ 0X pour la plate-forme cible). Sinon, il me semble que j'aime éviter l'utilisation de iostreams en 1997, simplement parce que la norme ISO C ++ n'a pas encore été publiée malgré le fait que tous les compilateurs leur ont déjà fourni de manière portable.

Si vous êtes tout d'accord, pourriez-vous me fournir des arguments que je pourrais utiliser pour renforcer ma position? Sinon, pourrais-je obtenir un peu plus de détails sur cette question "jusqu'à ce que le C ++ 0x est une idée standard"? BTW, quelqu'un sait quand ça va être?


2 commentaires

Souhaitez-vous quantifier ce que vous entendez par «à tout moment»?


@Neil jusqu'à ce que les alternatives viennent pour Windows & Linux, qui sont si bonnes qu'ils font de la GCC / MSVC obsolète.


5 Réponses :


8
votes

théorique mais pas pratique inconvénients de l'utilisation C ++ 0x:

  • rend plus difficile à porter à différents compilateurs.
  • ne pas adhérer à une norme publiée.

    Pratique Avantages de l'utilisation C ++ 0x:

    • rend votre vie quotidienne plus facile, donc plus productive.

      C'est un débat entre ce qui est théoriquement juste, et ce qui est pratique. Si votre équipe a une intention de faire quelque chose avec ce code, la pratique devrait l'emporter sur la théorie dix fois.


6 commentaires

En particulier si vous êtes absolument certain (comme vous semblez être) que vous n'allez pas porter ce code à un système dont le compilateur ne le comprend pas (encore). Je peux sympathiser avec les "normes" sont bonnes "pensant à votre collègue (éventuellement un peu aussi bien: p) mais s'il n'y a pas de conséquences négatives réelles, c'est juste un obstacle inutile.


Théorique, mais improbable, inconvénient de l'utilisation de C ++ 0x: en raison de bogues dans les deux implémentations que vous utilisez ou des modifications de la norme proposée, vous pouvez être piégé sur des versions spécifiques de GCC / MSVC. Exemple: si vous aviez fait cela il y a environ 7 mois et des concepts fortement utilisés. Voir aussi: Visual Studio 6.


Si les choses sont retirées de la norme, mais sont déjà implémentées dans les compilateurs, elles seront probablement transformées en une extension de compilateur en option au lieu d'être supprimée complètement. C'est donc, comme vous le dites, un désavantage théorique mais improbable.


Vous n'avez pas besoin de vous inquiéter de nombreuses fonctionnalités ajoutées / supprimées maintenant depuis mars FCD qu'ils ont des fonctionnalités figées et ne travaillent que sur les corrections / ajustements au projet de norme.


Merci pour la réponse! J'ai eu du mal à choisir entre votre réponse et Jalf, mais les deux étaient très informatifs. J'ai tendance à être d'accord sur le côté du côté pratique, mais je conviendrais également avec Jalf que nous devrions éviter les caractéristiques exotiques susceptibles de changer ou d'être retirée.


@THOMAS Un exemple de code sans extension: MSVC6 permet de renvoyer des objets ISTRingStream par valeur. Étant donné que la norme ne le fait pas, le seul moyen de résoudre le code que j'avais était de créer des macros. Heureusement, ils ne l'utilisent que dans un mk_stream (std :: string) fonction de type qui renvoyé un istringstream .



3
votes

Nous avions exactement le même problème, nous avons donc été compromis. Nous avons pris la version C ++ 0x TR1 et avons ensuite pris les portions que nous savions que nous voulions utiliser. Cela ressemble à beaucoup de travail, mais jusqu'à présent, ça a bien fonctionné. Nous utilisons les bibliothèques de regex, les tuples et quelques autres. Une fois que la norme est ratifiée, nous migrerons jusqu'au C ++ 0x. Cela n'est évidemment pas la meilleure solution, mais c'était un qui a bien fonctionné pour nous.


1 commentaires

+1 Merci Nathan pour un exemple auquel nous pouvons comparer. Je cherche un compromis similaire: il suffit d'aller avec les fonctionnalités de la FCD devenant déjà disponibles, pas plus les plus exotiques qui pourraient subir d'autres révisions.



7
votes

Une chose que vous n'avez pas besoin de (principalement) vous inquiéter (surtout) que les fonctionnalités soient ajoutées ou supprimées, car le projet de travail atteint " projet de comité final " (FCD) en mars. Les sages sur les caractéristiques doivent être gelés, le comité de normalisation n'acceptera plus de propositions pour C ++ 0x.

L'inconvénient est qu'il est encore un projet et non finalisé pour l'instant, le comité des normes est dans la phase de faire des corrections et des ajustements avant de finaliser et de publier la norme ISO (la libération attendue devrait être mars 2011). Cela pourrait signifier des modifications mineures syntaxiques ou sémantiques / comportementales qui pourraient rendre votre code non compilable ou ne pas fonctionner correctement une fois que vous compilez avec un compilateur plus standard conforme à celui que vous utilisez au moment où vous avez écrit le code.

Vous devrez probablement attendre des compilateurs comme VC ++ 10 pour obtenir la mise à jour avec des corrections / ajustements effectués.


1 commentaires

Merci, soulignant que le FCD est une bonne idée! Je pense que cela pourrait peut-être me permettre de gagner sur certaines personnes dans ce débat si nous choisissons de manière sélective quelles fonctionnalités C ++ 0X que nous pouvons utiliser.



10
votes

Je prendrais la décision sur une base par caractéristique.

N'oubliez pas que la norme est vraiment proche de l'achèvement. Tout ce qui reste est le vote, la fonction de bugiquer et davantage de vote.

Ainsi, une fonctionnalité simple comme auto ne va pas disparaître ou avoir changé sa sémantique. Alors pourquoi ne pas l'utiliser.

Les Lambdas sont suffisamment complexes pour que leur libellé ait changé et que la sémantique de quelques cas de coin fixe un peu, mais dans l'ensemble, ils vont se comporter comme ils le font aujourd'hui (bien que vs2010 ait quelques bugs À propos de la portée des variables capturées, MS a déclaré qu'ils sont des bogues et, comme on peut être fixé en dehors d'une version majeure du produit).

Si vous voulez y jouer, restez à l'écart de Lambdas. Sinon, utilisez-les où ils sont pratiques, mais évitez les cas super délicats, ou simplement être prêts à inspecter votre utilisation de Lambda lorsque la norme est finalisée.

La plupart des fonctionnalités peuvent être classées comme ceci, elles sont aussi simples et stables que leur mise en œuvre dans GCC / MSVC est exactement la manière dont ils vont travailler dans la norme finale, ou ils sont suffisamment délicats qu'ils pourraient obtenir Quelques bugsfixes appliquées, et ils peuvent être utilisés aujourd'hui, mais vous courez le risque de courir dans quelques arêtes brutes dans certains cas frontaliers.

Cela semble stupide pour éviter la fonctionnalité C ++ 0X uniquement parce qu'elles ne sont pas encore formalisées. Évitez les fonctionnalités que vous ne croyez pas être complètes, sans bug et stable, mais utilisez le reste.


3 commentaires

Merci Jalf pour le conseil! Je vais le prendre et voir si je peux convaincre mes collègues d'utiliser sélectivement certaines fonctionnalités de C ++ 0x. Pour fournir un petit fond, je suis dans une équipe qui est réticente à utiliser la bibliothèque standard sur ses propres collections manuellement manipulées. Une partie de la raison est qu'ils détestent la syntaxe d'itérateur. Lentement de plus en plus de personnes sont venues les utiliser car elles se rendent compte qu'il n'y a pas de bonne raison de ne pas le faire, mais il y a encore beaucoup de plainte concernant la syntaxe impliquée, par exemple, une itération pour la boucle. Ça ne me dérange pas depuis que je tapeef tout et la redondance syntaxique ne fait pas


[...] me dérange tellement plus (seulement la redondance logique), mais cela pourrait aider à obtenir plus de personnes à bord avec l'utilisation de C ++ correctement si nous venons d'avoir, disons, auto.


@ STINKY472: Il n'y a aucune raison de ne pas utiliser C ++ 0x si vous savez que vous avez un compilateur qui le supporte. N'oubliez pas que C ++ 0x peut offrir de nombreuses améliorations de performance et autres choses que C ++ 03 ne peut pas. Il est vrai que théoriquement, une fonctionnalité pourrait être modifiée. Mais le coût de la modification de la mise à jour lorsque vous mettez à jour et que la norme est terminée est beaucoup moins que le coût de ne pas utiliser les références de RValue, Auto, DeclType, des modèles variadiques.



1
votes

Si vous envisagez de rendre votre système Open Source dans un avenir pas trop loin, c'est un argument pour ne pas utiliser de trop de fonctionnalités de saignement. Un système de production exécutant Debian ou Red Hat n'a pas nécessairement d'installer un compilateur de bord de saignement.

Vous avez dit

Si nous avons déjà porté la base de code, les compilateurs sont également disponibles avec des fonctionnalités C ++ 0X également pour la plate-forme cible

Mais qu'un compilateur existe pour une plate-forme ne signifie pas toujours qu'il est installé / utilisé / recherché, en particulier sur les systèmes de production.

Si, d'autre part, vous avez l'intention de faire tout ce que vous vous compilez, ce n'est pas un problème.


1 commentaires

+1 merci lajnoïde et je n'ai pas considéré la distribution de Linux. Nous voudrons peut-être soutenir d'autres distributions pouvant être limitées aux versions plus anciennes de GCC. Je vais devoir lever ce point comme un problème légitime pour examen, mais j'espère que nous pourrons utiliser certaines des fonctionnalités de base C ++ 0X bientôt au lieu d'attendre des années avant que nous puissions en bénéficier.