Bonjour,
 
Voilà je cherche à faire en c un programme qui utilise une procédure pour faire la saisie et trier le tableau, cette procédure doit renvoyer le résultat au main qui se charge ensuite d'afficher le tableau.
 
j'ai des erreurs dans la compilation que je n'arrive pas à résoudre (je débute)
 
Un ptit coup de main serait le bienvenue
 
merci
 

Quelles sont tes erreurs ?
Ton compilo ?

 

 
le compilo c'est borland c++, j'ai pas de compilateur c sur cette machine

il faut remplacer tes *t[i] par t[i]
 
Par ailleurs, dans le main, tu déclares t comme un tableau (t[100]) donc c'est déjà un pointeur. Il faut que tu passes directement t (en pas &t) à ta fonction : saisie_tri (&n, t)
 
 
EDIT: visiblement, tu as quelques problèmes avec les pointeurs et les tableaux (normal, puisque tu débutes ). Je ne saurais trop te conseiller d'étudier bien à fond les chapitres concernant ce genre de sujet dans ton bouquin de C préféré.
 
Par ailleurs, pour prendre directement de bonens habitudes, il y a un certain nombre de points que tu devrais corriger dans ton programme: les entrées (scanf n'est pas si facile que ça à utiliser), la taille du tableau t (que se passe t'il si l'utilisateur entre plus de 100 nombres ?)

 
Merci,  
 
faut dire que j'étais pas encore arrivé au chapitre des pointeurs, va falloir que j'attende d'y arriver avant de jouer avec les fonctions
 
merci

 
j'essaie surtout d'avoir quelque bases, les contrôles de saisie je ne les fait du moment que c'est moi qui effectue la saisie pour les test
 
mais bon je pense que je vais attendre que le bouquin que j'ai commandé débarque parceque j'ai l'impression que je fais pas mal de conneries avec le cours sur lequel je bosse en ce moment
 
merci

Tu peux déjà t'amuser à condition de maitriser les notions suivantes
- un tableau contient l'adresse de son premier élément
ex: int t[100] => tu obtiens t[0], t[1], ..., t[99] PLUS "t" qui vaut "&t[0]"
- si tu incrémentes "t" de "n", tu obtiens l'adresse de l'élément "t[n]" autrement dit "t + n" <=> "&t[n]"
- si tu demandes "*(t + n)", tu obtiens "*&t[n]" donc "t[n]" (le & et le * s'annulant mutuellement)
 
Ensuite, avec ton bouquin, tu pourras regarder les détails plus poussés des manip pointeurs...

 
Merci
 
voilà j'ai changer le code, si quelqu'un pouvait me dire si c'est correct maintenant (en tout cas le programme marche), j'ai quelque question à posé par la suite
 

C'est correct, mais je recommande une meilleure organisation du code en 3 fonctions :  

Chaque fonction doit faire une chose et la faire bien.
 
La saisie devrait s'assurer qu'on ne dépasse pas le nombre d'éléments du tableau (un cinglé pourrait vouloir rentrer 101 ou plus éléments à la main !)
 
Pour savoir si le tri est correct, il faudrait prévoir des jeux de tests qui couvrent tous les cas, y compris les cas tordus (doublons, valeurs négatives etc.).

Salut
Enfait, je ne comprend pas pourquoi tu mais les deux argument de ta fonction void saisie_tri(int *n, int *t) avec des pointeur !
Je pourais bien comprendre pour le *t, mais là avec le *n Je dirai que ce sera mieu de passé un simple int n, la transmission se fera par valeur : void saisie_tri(int n, int *t)  .
Ensuite quand tu fait apel a ta fonction dans le mais() , tu fait saisie_tri(n, t) , sans avoire a ce soussier de passé l'adresse de n (&n) dans l'appel.  
( La trensmision se fera par valeur, càd la valeur de n qui se trouve dans ton main() se copie dans la variable n de ta fonction saisie_tri (l'argument de la fonction) ).
Mais c'est déja correcte et bien ce que tu a fait.
   
 

Parce que la fonction saisie le nombre d'élements...
L'affichage en a besoin après. C'est pour ça que j'ai suggéré un redesign...

 
 
Voir post d'Emmanuel Delahaye ci dessus

 
 
Je suis d'accord que le design est pas bon, mais c'était voulu, pour pouvoir travailler en transmission des données par adresse et non par valeur .

Il faut le faire quand c'est nécessaire... pas besoin d'en rajouter...
 

Oups j'ai parlais trop vite , lol , Je croyai qu'il a fait la saisi dans le main .    
 
EDIT: Mais, je pense que s'il fesai la saisi de (n) dans le main ce sera plus pratique (pourquoi vouloir compliquer les chose ? )
 
ou alors si tu tien vraiment a ce que ta fonction s'occupe aussi de la saisi de n , alors tu peut faire une fonction qui ne prend qu'un seul argument , et qui retourne le nombre d'élélent (càd le n qui a été saisi) :
int saisie_tri (int *t);
et dans l'appel:
n = saisie_tri (t);
 
mais bon    
 

Parce que, d'un point de vue organisationnel, le tableau est associé au nombre d'éléments qui le composent. Donc il est "naturel" que la fonction "saisie" s'occupe de tout ce qui concerne la saisie du tableau (à la fois le nombre d'éléments et à la fois chaque élément)
 

C'est faisable... mais cela gènera le "puriste". Déjà, il faut bien te dire que celui qui écrit une fonction et celui qui l'utilise ne sont pas forcément la même personne. Tu te vois écrire une fonction "saisie()" pour un programmeur avec qui tu travailles et lui dire "écoute, la fonction saisie() que je te file remplit toutes les valeurs du tableau mais ne fait que renvoyer son nb d'éléments - Si tu veux stocker ce nb, il faudra que tu le fasses toi-même" => Le programmeur te dira "ben zut, j'aurais bien aimé qu'elle fasse tout cette fonction comme ça je n'aurais pas eu à me préoccuper de quoi que ce soit...".
Par ailleurs, tu décides qu'une des valeurs sera renvoyée. Là ça va parce qu'il n'y en n'a qu'une en plus du tableau. Mais que feras-tu le jour où ta fonction doit stocker 4 valeurs. Tu en stockeras 3 et tu renverras la 4° ? Et sur quel critère tu décideras de la valeur qu'il faut renvoyer.
Enfin, dernier argument, il peut être judicieux de garder à ta fonction la possibilité de renvoyer un code "ok/erreur". Si tu utilises le "return" pour renvoyer le nb d'éléments, tu perds cette possibilité...

 
Je n'ai jamais dis que la fonction ne s'ocupera pas du nombre d'éléments du tableau, mais je parlais de la maniére de transmission de cette valeur a la fonction de saisi...    
 

 
Bon ok, tu ma convaincu    
 
 

Ces problèmes de conception d'interface de fonctions sont intéressants et méritent discussion.
 

 
   J'ai pas bien compris    , comment ca intéressants , du point de vu transmition de valeurs ?!
 

Je veux dire que la conception des interfaces des fonctions est un sujet qui mérite d'être approfondi, c'est tout.
 
C'est ce qui fait qu'une APi est facile à utiliser ou non, par exemple... ou qu'elle est plus ou moins performante. C'est un sujet qui, à ma connaissance, n'est pas enseigné et qui est, en général, laissé à l'appréciation de chacun sans véritable reflexion sur les conséquences de tel ou tel type d'interface.
 
On peut déjà passer en revue l'existant et faire la critique des fonctions de la bibliothèque standard, pour voir quelles sont les fonctions bien conçues et celles qui laissent à désirer (fgets() vs gets(), par exemple, mais il y en a d'autres comme localtime() etc....)