Ajoute un return à la fin de la fonction incriminée. (quant à la valeur retournée, à toi de voir ce que tu veux retourner)
Par contre, pense à utiliser les fonctions du header <algorithm> comme std::find_if dans le cas de cette même fonction.Il y a déjà un return i a la ligne 96
Il y a déjà un return i a la ligne 96
je dois ajouter un return0 après ?
- Edité par KyllianServières 30 août 2021 à 13:57:57
le code va compiler et fonctionner, sans problème.
Seulement, le compilateur va se rendre compte qu'il y a sans doute un cas auquel tu n'auras sans doute pas pensé: que se passe-t-il si la condition qui permet de renvoyer une valeur n'est jamais vérifiée?
Ben la réponse est simple: on arrive à la fin de la fonction, et il n'y a pas de renvoi de valeur, alors que la fonction est sensée renvoyer quelque chose.
Et donc, les concepteurs du compilateurs ont prévu le coup et on demandé au compilateur d'émettre un avertissement pour signaler le problème potentiel.
Tu remarqueras au passage qu'il ne s'agit que d'un avertissement: c'est un message qui t'est fourni, mais tu peux (hormis si tu as ajouté une option qui demande de traiter les avertissements comme s'il s'agissait d'erreurs) parfaitement décider d'ignorer ce message.
Après tout, tu peux estimer que les concepteurs du compilateur ont "simplement" réfléchi "un peu trop loin", car tu as la certitude que la condition sera respectée "à un moment ou à un autre".
Oui, mais, heu... en est on vraiment aussi sur que cela??? Car la condition, dans le cas présent, est basée sur la valeur d'une donnée qui est transmise en paramètre.
Or, cette valeur, ben, on ne sait pas d'où elle vient On ne sait pas, au niveau de la fonction, si la valeur transmise en paramètre est cohérente et correcte. Et on ne sait même pas si des vérifications ont été faites ou non pour s'assurer que cette valeur soit correcte et cohérente
Et donc, on ne peut absolument pas garantir que, quoi qu'il arrive, la condition sera forcément respectée à un moment ou à un autre à l'intérieur de la boucle. Et, par conséquent, on ne peut pas garantir que nous n'arriverons jamais à la fin de la fonction sans qu'elle ne renvoie une valeur (re )
Après, on peut ** peut-être ** s'intéresser au mécanisme qui permettrait d'arriver à la fin de la boucle sans que la condition ne soit vérifiée, et se dire que, si problème il y a, il provient d'office de l'appel de la fonction.
Si bien que l'on pourrait se dire que c'est le genre de problème qui devrait pouvoir être résolu "assez simplement" en rappelant à celui qui fera appel à la fonction d'effectuer les vérifications "qui vont bien".
pourrait alors être "largement suffisant", tout en ignorant l'avertissement émis par le compilateur.
Ou alors, on peut aussi se dire que celui qui appelle la fonction ne saurait pas faire la vérification avant d'appeler la fonction, vu que c'est -- justement -- la boucle qui permet de s'assurer que le paramètre reçu est "cohérent et correct".
Et là, il va alors falloir s'interroger sur la réaction la plus "cohérente" à avoir face à ce problème.
Car, si on arrive à la fin de la boucle, nous sommes, littéralement, dans une situation d'exception: une situation qui ne devrait (normalement) pas se présenter, mais dont on ne peut pas garantir qu'elle ne surviendra jamais, contre laquelle on ne peut strictement rien faire pour éviter qu'elle ne se produise, et à laquelle nous n'avons absolument pas les moyens d'apporter une solution si elle vient à se produire.
Dans l'idéal, il faudra donc arrêter séance tenante le traitement en cours, annuler tous les traitements qui ont pu être effectués avec les jeu de données actuel (celui dont le paramètre fait partie), et remonter au moins jusqu'à l'endroit où la valeur servant pour le paramètre sera récupérée, car ce sera à peu près l'endroit du code où l'on aura la possibilité de résoudre le problème.
Alors, ce qui est chouette, c'est que C++ est un langage à exceptions, et donc, que nous pourrions lancer systématiquement une exception (throw xxx; ) après la boucle, vu que, si on quitte la boucle, c'est que la condition que l'on pensait infaillible n'a jamais été remplie. Nous pourrions alors mettre un try ... catch "beaucoup plus haut" dans le code pour nous donner "une chance" de résoudre le problème s'il venait à se poser.
Malheureusement, si notre code est destiné à travailler avec des bibliothèques C, les exceptions ne sont sans doute pas une option.
Dans ce cas, il faudra prévoir de renvoyer une valeur connue pour représenter une valeur invalide et qui sera systématiquement vérifiée au niveau de la fonction appelante.
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
control reaches end of non-void function [-Werror=
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Si vous ne trouvez plus rien, cherchez autre chose.