2010-03-15 10 views
12

J'apprends c++0x, au moins les parties prises en charge par la version bêta de Visual C++ Express 2010. Ceci est une question sur le style plutôt que sur la façon dont cela fonctionne. Peut-être qu'il est trop tôt pour le style et de bonnes pratiques pour avoir évolué encore une norme qui est même pas encore sorti ...Fonction type de retour de type

En c++0x vous pouvez définir le type de retour d'une méthode utilisant -> le type à la fin de la fonction au lieu de mettre le type au début. Je crois que ce changement de syntaxe est nécessaire en raison de lambdas et de certains cas d'utilisation du nouveau mot-clé decltype, mais vous pouvez l'utiliser n'importe où pour autant que je sache.

// Old style 
int add1(int a, int b) 
{ 
return a + b; 
} 

// New style return type 
auto add2(int a, int b) -> int 
{ 
return a + b; 
} 

Ma question alors vraiment, est donné que certaines fonctions devront être définies dans la nouvelle façon est-il considéré comme un bon style pour définir toutes les fonctions de cette façon pour la cohérence? Ou devrais-je m'en tenir à l'utiliser uniquement lorsque cela est nécessaire?

+5

Rasoir d'Occam: Étant donné deux constructions de code équivalentes, la plus simple est la meilleure. –

+0

Btw, Visual Studio 2010 RC1 est déjà sorti – abatishchev

+0

Oui c'est RC1 (express) que j'utilise. Je me suis trompé de version dans mon article – jcoder

Répondre

18

Ne considérez pas le style juste pour être cohérent. Le code devrait être lisible, c'est-à-dire compréhensible, c'est la seule vraie mesure. Ajoutant le fouillis à 95% des méthodes pour être cohérent avec l'autre 5%, eh bien, cela ne me semble pas juste.

+0

J'ai accepté cette réponse car elle résume la discussion et a le plus de votes de toute façon. Les autres réponses sont toutes bonnes, merci – jcoder

2

Il me semble que ce serait en train de changer l'habitude d'une vie pour beaucoup de C++ (et d'autres C comme) les programmeurs.

Si vous avez utilisé ce style pour chaque fonction alors vous pourriez être le seul à le faire :-)

5

Il y a une énorme base de code qui utilise les « anciens »/règles actuelles. Je parierais que ça va durer longtemps. Le problème de cohérence est double: avec qui allez-vous être cohérent, le peu de code qui nécessitera la nouvelle syntaxe ou tout le code existant?

Je garderai avec l'ancienne syntaxe lorsque le nouveau n'est pas nécessaire pour un peu, mais là encore, seul le temps dira ce que devient l'usage commun.

Notez également que la nouvelle syntaxe est encore un peu bizarre: vous déclarez le type de retour auto puis définissez ce que auto signifie à la fin de la déclaration de signature ... Cela ne semble pas naturel (même si vous ne le faites pas comparer avec votre propre expérience)

2

Je vais deviner que la norme actuelle va gagner, comme il l'a à ce jour avec tous les changements proposés à la définition. Il a été étendu, bien sûr, mais la sémantique essentielle de C++ est tellement intégrée que je ne pense pas qu'ils valent la peine de changer. Ils ont influencé tant de langues et le style guide son ridicule. Pour ce qui est de votre question, je vais essayer de séparer le code en modules pour bien préciser où vous utilisez l'ancien style par rapport au nouveau style. Où les deux mélanger je m'assurerais et délimiterai autant que possible. Les regrouper, etc.

[opinion personnelle] Je trouve vraiment discordante de naviguer à travers les fichiers et regarder le style morph en arrière, ou changer radicalement. Je me demande juste ce qui se cache là-dedans [/ opinion personnelle]

5

Personnellement, je l'utiliserais quand il le faut. Tout comme this-> n'est nécessaire que pour accéder aux membres d'un modèle de classe de base (ou lorsqu'il est caché), auto fn() -> type n'est nécessaire que lorsque le type de retour ne peut pas être déterminé avant que le reste de la signature de la fonction soit visible.L'utilisation de cette règle empirique aidera probablement la majorité des lecteurs de code, qui pourraient penser "pourquoi l'auteur pense-t-il que nous devons écrire la déclaration de cette façon?" autrement.

1

De bons changements de style - si vous ne me croyez pas, regardez ce qui était bon style en 98 et ce qui est maintenant - et il est difficile de savoir ce qui sera considéré comme un bon style et pourquoi. À mon humble avis, actuellement tout ce qui touche à C++ 0X est expérimental et le qualificatif bon ou mauvais style ne s'applique tout simplement pas, pour le moment.

5

Je ne pense pas qu'il soit nécessaire de l'utiliser pour des fonctions régulières. Il a des usages spéciaux, vous permettant de faire facilement ce qui aurait pu être assez gênant auparavant. Par exemple:

template <class Container, class T> 
auto find(Container& c, const T& t) -> decltype(c.begin()); 

Ici, nous ne savons pas si Container est const ou non, donc si le type de retour serait Container::iterator ou Container::const_iterator (peut être déterminé à partir de ce begin() retourneraient).