Le mot cl� continue en C++

�a tue pas les exceptions :)

je ne dit pas que cela tue, je dit simplement qu'il ne faut pas en abuser.

Et c'est justement le but de la programmation par exception (qui �tait � la mode il n'y a pas si longtemps).....

apr�s j'ai peu �tre mal choisi mes mots, il y'a aussi des endroits ou tu n'as pas le choix (pour les exception).

Je crois quand m�me qu'il ne faut pas tout m�langer...

D'un cot� il y a le goto, qui *peut exceptionnellement* pr�senter certains int�r�ts, mais dans des situations tout � fait particuli�res.

En toute honn�tet�, je n'ai jamais du y avoir recours, et je ne m'en porte pas plus mal: si on ne reste pas bloqu� sur le principe (qui est devenu totalement obsol�te) du SESE d�j� �voqu�.

Si on prend cinq minutes de r�flexion au lieu de se jeter directement sur son clavier et de se mettre � "vomir" du code, on arrive parfaitement � s'en passer, et c'est tout b�nef pour la lisibilit� du code.

A l'extr�me oppos�, on a le syst�me d'exception. Mais on est donc tent� de s'int�resser � ce qu'est une exception.

Ta vision qui essaye de dire qu'une exception doit �tre... exceptionnelle est finalement fort restrictive: quand on regarde les diff�rentes exceptions lanc�es par la STL, on remarque en effet que s'il y a deux points communs entre toutes les exceptions, c'est:

• effectivement des �v�nements qui ne se produisent (par chance) que rarement ou dont on peut dire que "ils peuvent arriver"
• des probl�mes dont la source et, par la m�me occasion, les opportunit�s d'y apporter �ventuellement une solution, se trouve g�n�ralement (largement) en amont:
  • Si new �choue, ce sera le plus souvent parce que... trop de m�moire est d�j� allou�e dynamiquement
  • Si l'ouverture (enfin, si l'acc�s � un fichier r�put� ouvert) d'un fichier �choue, c'est sans doute parce qu'il a �t� "verrouill�" par le syst�me par ailleurs (souvent en dehors de l'application, d'ailleurs :P), ou parce que l'on a commis une erreur lorsqu'il a �t� question d'�valuer le nom (et le chemin d'acc�s) du fichier.
  • Si la fonction at de la classe vector �choue, c'est, typiquement, parce que l'on a mal �valu� le nombre d'�l�ments
  • Si un transtypage (static_cast ou dynamic_cast) devant fournir une r�f�rence �couhe, c'est, typiquement, parce que l'on a mal identifi� le type r�el de l'objet r�f�renc�.

Le but d'un bloc try... catch est en r�alit� double:

• Il nous donne la possibilit� de remettre le syst�me dans un �tat coh�rent si un �v�nement "qui n'aurait pas du se produire" s'est produit, par exemple, en annulant des modifications qui n'avaient de sens que parce que l'on esp�rait que l'�v�nement incrimin� ne se produise pas.
• Il nous donne l'occasion de remonter � la source du probl�me, afin d'�viter qu'il ne se reproduise par la suite (s'il est possible d'y trouver une solution, du moins)

Il ne faut pas non plus oublier qu'une exception transporte avec elle une information de contexte des plus utiles: les diff�rentes �v�nements cit�s plus haut lancent tous une exception diff�rente (m�me si elles ont toutes une base commune), ce qui permet, lorsqu'on la r�cup�re (parfois bien haut par rapport � l'endroit o� l'�v�nement s'est produit), d'apporter la meilleure r�ponse possible au probl�me.

D�s lors, s'il est, effectivement, aberrant de vouloir placer du try... catch partout o� une exception risque d'�tre lanc�e (un simple vector.add(value) peut en lancer une, vu que add risque d'appeler new, qui peut lancer une exception :aie::D), il est tout aussi aberrant de vouloir comparer try... catch � un simple goto ;)

Mais cela nous �carte du probl�me du PO... Et il existe d�j� des d�bats relatifs aux avantages du goto et, je crois, des exceptions.

Je proposerais donc de recentrer le d�bat sur sa question existentielle qui concerne le continue.

Je l'ai d�j� dit, je n'ai jamais eu � me servir d'un break en dehors d'un switch, case et je n'ai jamais eu besoin de me servir de continue.

Il serait bien sur pr�somptueux de ma part de dire que c'est peut �tre parce que je suis un bon programmeur, mais je constate que les circonstances m'ont toujours permis de m'en passer ;)

Et je ne peux m'emp�cher de rappeler encore une fois qu'aucune technique de programmation ne peut �tre consid�r�e comme la solution ultime � tous les probl�mes, et que son utilit� doit imp�rativement �tre �valu�e en fonction des circonstances auxquelles nous sommes confront�s.

L'instruction continue ne fait pas exception: S'il est vrai que, tr�s souvent, son besoin est de nature � au minimum tirer une sonnette d'alarme qui devrait t'inciter � r�fl�chir sur l'opportunit� d'un refactoring et / ou de la factorisation de ton code, il y a des cas o� il devient impossible de s'en passer sans provoquer une complexification nuisible de la logique ou du code.

Dans ce genre de cas, son utilisation est, non seulement justifi�e, mais aussi sans doute tr�s largement pr�f�rable � toute autre solution ;)

Personellement, je me reposer la question initiale a chaque fois que je tombe sur un cas o� je doute.

Ce qui fait que je fais du "cas par cas". Donc parfois je l'utilise.


Il m'arrive souvent de faire des fonctions de recherche sous cette forme (pseudocode) :

Code:

---

1 2 3 4 5 6 7 8

fonction findMachin( string name ) return Machin   for each machin in machins if machin.name == name return machin   return null end

---

C'est pas des continue mais c'est le m�me genre de questionnement non?

Pour les continue, il m'arrive d'en faire quand j'ai besoin de parcourir les �l�ments d'un conteneur pour faire plusieurs tests de "validation" avant d'effectuer une action dessu :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

fonction validation()   for each machin in machins   if machin.name == "" || !isConditionA( machin ) // etc... continue   //toutes les conditions sont passées action( machin ) end

---

Mais souvent quand le code prends plusieurs lignes ou aparait comme utilisable ailleurs, je factorise :

Code:

---

1 2 3 4 5 6 7 8 9 10

fonction validation()   for each machin in machins   if checkAllConditions( machin ) action( machin ) end   function checkAllConditions( Machin machin ) return bool //...

---

Du coup, beaucoup de continue pourraient �tre remplac�s par une fonction avec un retour booleen.

Ca m'arrive quand m�me d'en utiliser mais seulement quand je n'ai pas pris le temps de refactorer une fonction ou bien quand le code reste suffisamment simple pour rester lisible m�me apres l'ajout du continue.

Salut,

Citation:

---

Envoy� par Klaim

C'est pas des continue mais c'est le m�me genre de questionnement non?

---

Pour moi, c'est pas tout � fait la m�me chose en terme de lecture de code. Un return, tu vois bien que tu sorts directement de la fonction.
Les break/continue que j'ai vu c'�tait plut�t comme screetch les d�crit :

Code:

---

1 2 3 4 5 6

{ if(blablabla) break; /* plein de trucs */ if(dobidouwa) break; /* plein de trucs */ }

---

Et comme le dit Luc, le probl�me c'est /* plein de trucs */.
Cependant, j'ai l'impression que si on n'avait pas /* plein de trucs */, on n'aurait pas besoin de break/continue.

Je me sers de continue de temps en temps (12 occurrences sur 40 000 lignes de code, c'est pas �norme non plus).
La plupart du temps, c'est pour changer :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

for (...) { // Faire deux trois choses (ou rien du tout) if (caVaMal) { // Traiter le cas qui ne fonctionne pas } else { // Poursuivre le traitement } }

---

... en :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

for (...) { // Faire deux trois choses (ou rien du tout) if (caVaMal) { // Traiter le cas qui ne fonctionne pas continue; }   // Poursuivre le traitement }

---

Je trouve que �a am�liore la lisibilit� (on vois tout de suite avec continue que le traitement est abandonn� pour cette it�ration), et �a �vite d'avoir trop d'indentation...

D'autre fois c'est simplement une question d'algorithme. Par exemple en d�tection de collision entre deux objets 3D, on essaye de faire un minimum de traitement pour chaque triangle du maillage. On passe donc � l'it�ration suivante d�s qu'on est s�r que le triangle qu'on �tudie n'entrera pas en collision, d'o� l'emploi de continue.

Honn�tement, si vous savez lire un return ailleurs qu'en fin de fonction, alors je ne vois pas de probl�me � mettre des break et des continue partout :) (bon, avec mod�ration comme toutes les bonnes choses). C'est la m�me gymnastique intellectuelle.