Concernant la propreté...

Citation:

---

Envoyé par JolyLoic

Mais là, plus d'accord.

---

Meuh si. Parce que c'est "préféré par le staff de l'école" qu'il faut lire :)

Citation:

---

S'il y a une variable qui sert naturellement de compteur à la boucle (elle s'incrémente une fois et une seule à chaque itération de la boucle), je trouve que la boucle for est plus claire à lire. Ne serait-ce que parce qu'il y a séparation plus claire entre le code de l'itération et le code décrivant ce qui a lieu pendant l'itération.

---

Même sans variable compteur :

Code:

---

1 2 3

for (iterator i= v.begin(); v != end(); ++v) { } // pour le C++ for (llnode* node = list->start; node != NULL; node = node->next) { } // pour le C

---

Sont deux formes de boucle idiomatiques et très lisibles. Les cas sont rares où une boucle while apporte vraiment en lecture ou en écriture de code. findfirst/findnext (parcours de répertoire) couvre un cas typique ;

Personnellement, j'ai généralement 85% de boucles for, 10% de boucles while, et 5% de boucles do/while, donc tu n'as pas à me convaincre. Dans mon prohet actuel (5000 lignes de code de pur C++) :

26 boucles for
2 boucles while
1 boucle do/while

Je crois que c'est assez parlant :)

(et la boucle do/while est en fait une protection pour encadre une macro :

Code:

---

1 2 3 4 5 6 7 8

#define ACCEPT_VISITOR(type, v) \   do { \   type* __visitor = dynamic_cast<type*>((v)); \   if (__visitor) { \   __visitor->accept(this); \   } \   } while (0)

---

Les deux autres boucles while sont :
* parcours de répertoire

Code:

---

while ((entry = ::readdir(directory)) != NULL)

---

(parce que dans une boucle for, ça fait pas naturel du tout).

* recherche répéte de la position d'un caractère particulier dans une chaine

Code:

---

while ((pos = out.find(L'\\', pos)) != std::wstring::npos)

---

(même remarque).

Les boucles for (en direct live d'une sortie grep):

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

compiler_generator_restriction_builder.cpp: for (n_type i = node.first_child(); i != node.last_child(); ++i) compiler_generator_restriction.cpp: for (std::size_t i = 0; i < m_conditions.size(); ++i) compiler_generator_restriction.cpp: for (std::size_t i=0; i<m_conditions.size(); ++i) compiler_generator_simple_type_builder.cpp: for (n_type i = node.first_child(); i != node.last_child(); ++i) compiler_generator_simple_type.cpp: for (std::size_t i=0; i<m_subgens.size(); ++i) compiler_schema_xsd_builder.cpp: for (a_type i = n.first_attribute(); i != n.last_attribute(); ++i) compiler_schema_xsd_builder.cpp: for (n_type i = root.first_child(); i != root.last_child(); ++i) tpl_template_engine.cpp: for (std::size_t i=0; i<m_files.size(); ++i) tpl_template_generator.cpp: for (std::size_t i = 0; i < m_iterations.size(); ++i) tpl_template_generator.cpp: for (variable_iterator i = m_variables.begin(); i != m_variables.end(); ++i) tpl_template_generator.cpp: for (std::size_t i=0; i<m_conditions.size(); ++i) tpl_template_generator.cpp: for (std::size_t i = 0; i < m_variable->size(); ++i) tpl_template_generator.cpp: for (block_iterator i = m_blocks.begin(); i != m_blocks.end(); ++i) tpl_template_generator.cpp: for (block_iterator i = m_blocks.begin(); i != m_blocks.end(); ++i) utils_command_line.cpp: for (int i = 0; i < ac; ++i) utils_command_line.cpp: for (std::size_t i = 0; i < m_options.size(); ++i) utils_command_line.cpp: for (std::size_t i=0; i<m_handlers.size(); ++i) utils_command_line.cpp: for (std::size_t i = 0; i < m_options.size(); ++i) utils_command_line.cpp: for (std::size_t i=0; i<m_handlers.size(); ++i) utils_transformer.cpp: for (std::size_t i=0; i<tlist.size(); ++i) utils_transformer.cpp: for (std::size_t i=0; i<m_ops.size(); ++i) utils_transformer.cpp: for (std::size_t i=0; i<out.length(); ++i) xml_details_iterator.h: for (std::size_t i = 0; i < n; ++i) xml_details_iterator.h: for (std::size_t i = 0; i < n; ++i) xml_node.cpp: for (a_type i = n.first_attribute(); i != n.last_attribute(); ++i) xml_node.h: for (xmlNodePtr child = m_node->children; child != NULL; child

---

Parcours de collection en utilisant un index ou un itérateur, et parcours de la liste des children d'un noeud XML (merci libxml2 pour ton interface si jolie... hum).

Citation:

---

Envoyé par JolyLoic

Et pour les initialisations, vu que tu as l'air de connaitre ces règles "de l'intérieur" tu confirmes que ce sont des règles faites avec le C en tête ?

---

Je le confirme. Connaissant Nicolas Sadirac, je suis même surpris qu'il accepte le C++. Il a du mettre de l'eau dans son vin :)

Citation:

---

Envoyé par Emmanuel Deloget

Je le confirme. Connaissant Nicolas Sadirac, je suis même surpris qu'il accepte le C++. Il a du mettre de l'eau dans son vin :)

---

D'un autre côté, la norme présente au lien donné par RT222 est clairement orienté C. Je ne vois rien dedans qui fait mention de C++.

Au passage, la règle concernant l'initialisation des variables en C, même si elle est moins surprenante qu'en C++, reste discutable (surtout donné sans motivation).

Mea Culpa, il me semble vous avoir induits en erreur. :oops: En effet, cette norme s'applique au C et à lui seul. J'ai terminé la première année d'Epitech où l'on ne pratique que du C, je ne commencerais le C++ que lors de ma seconde année, qui commencera le 03 Janvier à venir. Je ne sais donc pas encore quelle norme nous auront à respecter pour ce langage. En tout cas, elle sera nouvelle, car le fait de faire du C++ en deuxième année est inédit dans l'école (auparavant c'était une année dédiée au PHP, que les étudiants trouvaient trop facile après le C de la première année).

Le C++ que je pratique actuellement ainsi que le moteur 3D sur lequel je travaille sont des projets bien personnels n'ayant aucun lien avec Epitech. Quand je disais que la norme de l'école ne m'aidait pas à coder proprement, je voulais dire que m'étant basé dessus toute une année, et le C ayant des similarités avec le C++, les réflexes d'écriture que j'ai acquis dans le premier reviennent naturellement dans ce dernier. J'espère avoir été moins ambiguë cette fois. :P

Citation:

---

Envoyé par RT222

Mea Culpa, il me semble vous avoir induits en erreur. :oops: En effet, cette norme s'applique au C et à lui seul. J'ai terminé la première année d'Epitech où l'on ne pratique que du C, je ne commencerais le C++ que lors de ma seconde année, qui commencera le 03 Janvier à venir. Je ne sais donc pas encore quelle norme nous auront à respecter pour ce langage. En tout cas, elle sera nouvelle, car le fait de faire du C++ en deuxième année est inédit dans l'école (auparavant c'était une année dédiée au PHP, que les étudiants trouvaient trop facile après le C de la première année).

Le C++ que je pratique actuellement ainsi que le moteur 3D sur lequel je travaille sont des projets bien personnels n'ayant aucun lien avec Epitech. Quand je disais que la norme de l'école ne m'aidait pas à coder proprement, je voulais dire que m'étant basé dessus toute une année, et le C ayant des similarités avec le C++, les réflexes d'écriture que j'ai acquis dans le premier reviennent naturellement dans ce dernier. J'espère avoir été moins ambiguë cette fois. :P

---

Pas de mal. Je me disais aussi... :)

Après concernant la norme C++, je ne me rappelle de rien concernant ce point dans ma scolarité passée. Je ne crois pas qu'une telle norme existe au sein d'Epit{a,tech}. Mais en même temps, ça remonte à relativement loin...

C'est vrai que la norme C permet de programmer proprement. Certains points sont clairement exagérés par rapport aux besoin - comprendre qu'on peut continuer à programmer très proprement en éliminant certains points de cette norme.

Le principal, au final, c'est d'avoir un code agréable à regarder. Et l'idée pour le voir, c'est de se mettre à 5m de l'écran, et de voir le motif général qui se dégage : si tu vois des gros pâtés, c'est qu'il y a un problème :)

Code:

---

for (llnode* node = list->start; node != NULL; node = node->next) { } // pour le C

---

Sauf que cette syntaxe est pas légale en C :>.... (déclaration dans le for)

Citation:

---

Envoyé par Goten

Code:

---

for (llnode* node = list->start; node != NULL; node = node->next) { } // pour le C

---

Sauf que cette syntaxe est pas légale en C :>.... (déclaration dans le for)

---

Voui :) Alors disons "pour le code obsolète" ou "pour les interfaces C" :)

<HS>

Citation:

---

Envoyé par Goten

Code:

---

for (llnode* node = list->start; node != NULL; node = node->next) { } // pour le C

---

Sauf que cette syntaxe est pas légale en C :>.... (déclaration dans le for)

---

sauf erreur de ma part, c'est valide en C99 (qui est la norme courante du C). C'était invalide en C90.

</HS>

Tout à fait, mais rare sont les projets dans lesquels je travaille où on utilise du C99 (notamment à cause du support des compilos).
D'ailleurs g++ ne compile pas en C99 par défaut.

Citation:

---

Envoyé par Goten

D'ailleurs g++ ne compile pas en C99 par défaut.

---

Effectivement, par défaut c'est, pour le C, du gnu90 si ma mémoire est bonne (je ne suis pour ainsi dire jamais en mode par défaut, j'ai au moins un -ansi qui traine).