bonjour j'ai une fonction a crée pour ensuite la mettre dans un programme et je comprend absolument rien j'ai lu et relu je cour plusieurs fois voila l'énoncer: Aider moi SVP  
 
Ecrire une fonction qui reçoit en paramètre un nombre entier et qui retourne vrai si ce nombre est premier ou
faux sinon . (fonction: bool premier(int )
Rappel : un nombre entier est premier s'il n'a que 2 diviseurs distincts : 1 et lui même

Ben montres nous déjà le code que tu as commencé à écrire.
Et les idées que tu as sur la méthode a utiliser pour tester si un nombre est premier ou pas.
 
A+,

En C je dirais que ça donnerait un truc comme ça :

 
Dès qu'il va détecter qu'un reste est à 0, il renvoi directement false, la boucle s'arrête (pas besoin de vérifier les autres)
A la fin de la boucle, la fonction renvoi vrai (Ceci-dit, bool existe bien en C, non ? ).

il n'y a pas de bool en C mais pour le reste je valide (avec un while)

Bien sur que si, il suffit de faire  
#include <stdbool.h>
et de ne pas vivre avec un compilo de l'âge des cavernes.
A+,

Note : Si vous voulez absolument optimiser, autant ne tester que les nombres impairs (et gérer le cas de 2 à part), cela économise la moitié du boulot

Après, tu peux toujours faire ça :  

 
Comme ça, la fonction n'est signée que sur un seul octet (sauf cas particulier, mais il me semble que toute les machines interpréterons un char comme un seul octet et un w_char comme 2 octets)

Et ne pas non plus chercher un diviseur plus grand que la racine carrée du nombre, bref un truc de ce genre:
 

A+,

Noter que pour la declaration de i comme int dans la boucle
for (int i=2;i<nombreEntier;i++)
faut au moins être en C99 pour qu'un compilo l'accepte.
 
A+,

 
 
Votre code renvoie vrai pour la valeur 1, et faux pour la valeur 2, ce qui est manifestement erroné. De plus, les nombres négatifs sont mal gérés (surtout l'appel à sqrt )...
 
Ma proposition (je n'aime pas les accolades ouvrantes en début de ligne et les instructions sans accolades après un if/for/while ... et j'aime bien qu'une fonction non-void se termine par un return)
 

Ben 1 est premier, donc :
 
if (nombreEntier<=2)
 return true;
 
C'est juste que Gilou n'a pas traité le nombre 2, et comme 2%2 = 0 , ça renvoi faux

Je ne peux pas vous laisser dire ça  

Que faites-vous de l'unicité de la décomposition en facteurs premiers, si 1 l'est ?

De plus, votre formulation du test renvoie vrai pour 0, -1, -2, ...

les nombres negatifs ne peuvent pas etre premier par definition

et 1 n'est pas premier

J'ai pas prétendu que c'était la solution finale, mais qu'il pouvait s'en inspirer. A lui ensuite de l'adapter à son code, la c'était pour lui montrer qu'on pouvait diviser par 4 le nombre de tour de boucles. Mea culpa, j'aurais du préciser qu'il devait s'occuper à part des nombres précédent la borne inférieure de la boucle, mais ça me semblait évident.
On pouvait encore optimiser avec une table statique des nombres premiers de 1 à 30 ou 50 qui sont en général bien connus (c'est ainsi qu'on règle le cas de 0, 1, 2, 3, 5...) habituellement.
 
Quand à ne pas traiter les nombres négatifs, c'est tout à fait normal, car je ne sais pas quelle définition des nombres premiers est adoptée pour son exercice:

Avec une telle définition, il n'y a pas de nombre premiers, tout nombre entier étant divisible par 1, -1, lui même et son opposé.
Avec la définition un nombre entier naturel est premier s'il n'a que 2 diviseurs entiers naturels distincts : 1 et lui même, la on a une définition qui marche. Et si on considère les entiers relatifs, c'est une question de point de vue.
 
A+,

ça dépend de ta définition, cf mon post précédent.
La notion de nombre premier n'est bien définie et n'a de sens que pour les entiers naturels. Ensuite quand on passe aux entiers relatifs, il y a deux manières de l'étendre (grosso modo n est premier comme entier relatif s'il l'est comme entier naturel ou bien n est premier comme entier relatif si |n| l'est comme entier naturel) et choisir l'une ou l'autre n'a pas grande importance.
 
A+,

- Pour les accolades, il y a eu plusieurs études montrant que le style que j'ai adopté générait moins d'erreurs de relecture. C'est pourquoi j'ai changé de style et adopté celui qui est le plus efficace.
- les instructions uniques sans accolades c'est une question de gout, je trouve cela plus lisible on veut clairement indiquer qu'une action et une seule doit être effectuée, ce qui est le cas avec un return.
- Je préfère que le compilateur puisse m'indiquer un return manquant dans le code, ce qu'il ne pourra faire s'il y a un return inutile final.
 
A+,

Pour le premier point, je trouve personnellement que c'est moins lisible, mais c'est là-encore une affaire de goût !
 
Pour le troisième, je ne suggère pas de mettre un return "inutile" à la fin du code, d'ailleurs, dans mon exemple, le return final est utile. Disons que c'est un compromis entre la règle "pas de return dans le code de la fonction", que je trouve un peu lourde à gérer au final et le fait de ne pas en avoir à la fin. Et, sauf erreur de ma part, avec les options par défaut, g++ n'émet pas de warning pour un return manquant (ce que j'ai toujours trouvé assez incompréhensible). Comme je n'ai pas eu le courage de lire ce que disent les normes C/C++ sur ce sujet ...

Tiens, au fait, pourquoi ne pas faire ça de manière fonctionnelle, en exploitant la tail-recursion...
 

 
A+,

Le code est élégant, mais peut consommer pas mal de pile, pour de grandes valeurs de n !!
 
Le stack overflow nous guette !!

Justement avec ce type de code, ce n'est pas nécessairement le cas.
Un compilo qui sait gérer correctement ce type d'appel récursif ne va pas faire d'empilement, mais va ré-exploiter le même emplacement mémoire pour les passages de paramètre successifs.
A+,

voire il va faire de derecursifiage.