Pour chipoter, string.h n'est pas une bibliothèque =)
D'une manière générale, on lie une bibliothèque et on inclut son interface.
C'est vrai que quand on présente une fonction, ça me semble le minimum de signaler dans quel header elle est déclarée et quel est son prototype. Mais on peut ausi considérer que ça fait doublons avec la doc (man 3 strcmp (ou google strcmp, ça marche aussi =P)).
En fait l'idée, c'est que les habitués qui répondent aux questions disent simplement « va voir dans la FAQ, la réponse y est » lorsque c'est le cas.
Le problème c'est qu'il y a toujours des petits malins qui veulent faire les beaux, et ignorent totalement ton post, et répondent quand même !! (j'ai vécu ça, j'ai longtemps combattu les posts qui n'utilisaient pas les balises, mais à chaque fois que je signale qu'il faut utiliser les balises, t'as un ptit con juste après qui répond au PO, comme si genre toi t'avais pas su répondre -_-')
A mon avis il faut être un peu plus radical, locker les posts qui posent des questions qui sont dans la FAQ, après s'il s'avère que le PO ne trouve pas ce qu'il veut dans la FAQ, il ouvre un nouveau topic, et précise bien qu'il est allé voir la FAQ, et que ça ne l'a pas aidé.
C'est un poil trop extrême en mon sens. Pour les sujets qui présentent d'autres problèmes, pas ou peu de politesse, mauvais titre, pas de balises code ou autres, on peut sûrement fermer.
Mais sinon, tu peux donner le lien vers la FAQ en disant « tu trouveras ta réponse ici ». Et tu ajoutes quelque chose comme « pense à jeter un œil là bas avant de poster la prochaine fois ! ». De cette manière, tu réponds effectivement au PO, ce qui te « protège » en quelque sorte des autres réponses. Dans les cas les plus extrêmes, tu peux même citer la page.
Si tu tombes sur un réfractaire qui refuse complètement de suivre tes liens et qui demande plus de détails sur la réponse, alors que tu as déjà donné ces détails dans ton lien, tu signales.
J'ai déménagé sur Zeste de savoir — Ex-manager des modérateurs.
Si tu tombes sur un réfractaire qui refuse complètement de suivre tes liens et qui demande plus de détails sur la réponse, alors que tu as déjà donné ces détails dans ton lien, tu signales.
Je propose une nouvelle question à la FAQ, qui pourrait aller dans [8] Les inclassables :
[8][X] Qu'est-ce que size_t, et quand l'utiliser ?
'size_t' est un type d'entier non-signé (c'est-à-dire positif). Il est définit selon les systèmes par :
typedef unsigned int size_t
ou par :
typedef unsigned long int size_t
'size_t' est défini dans les fichiers d'en tête stdio.h, stdlib.h, stddef.h, et string.h.
'size_t' est utilisé pour définir la taille des chaînes ou d'éléments. Il convient parfaitement à la valeur que renvoie sizeof(), aux indices de tableaux, ou encore pour définir la taille d'un élément lors d'une allocation dynamique :
/* Utilisation du size_t comme paramètre de taille lors d'une malloc() : */
size_t tailleChaine = 500;
maChaine = malloc(tailleChaine);
/* Utilisation du size_t pour stocker le nombre de membres d'une chaine : */
size_t longChaine = 0;
longChaine = strlen(maChaine);
/* Utilisation du size_t comme indice de tableau : */
size_t i = 0;
maChaine[i] = 0;
/* Utilisation du size_t pour recueillir la valeur donnée par sizeof() :*/
size_t tailleChaine = 0;
tailleChaine = sizeof(maChaine);
Voilà pour mon idée. Bon, je ne suis pas un exceptionnel générateur d'exemples (mais j'en connais ^^), et ce dernier est peut-être à améliorer. Quand à size_t, je pense avoir dis le minimum, mais je me demandais quelque chose : est-ce que ce type convient aux indices de tableaux ?
En espérant que cette question intègre la FAQ et qu'elle en aide plus d'un
EDIT : J'ai rajouté l'indice de tableau dans les exemples d'utilisations, mais je ne sais pas si c'est vraiment correct (d'ailleurs ça commence à allonger un peu trop la liste d'exemples pour une simple FAQ. Peut-être n'en faire que mention ? ).
En tous cas, me le dire si jamais ça n'est pas très conventionnel.
eh bien, si tu alloue de la memoire, admettons, un tableau de 8 chars... tu fais pointer un pointeur sur la 2° case de ce tableau, eh bien, putchar(nompointeur[-1]); affiche la valeur de la premiere case de ton tableau.
EDIT, enfin du moins c'est ce qu'il me semble, je vais re tester de ce pas
Donc malgré le fait que certains indices peuvent être négatifs (et c'est rare, je n'ai encore jamais croisé ce cas), le type 'size_t' est-il approprié voire recommandé pour cette utilisation ? (C'est surtout de savoir s'il est recommandé dans certains cas qui m'intéresse surtout, sinon pas besoin d'y faire mention dans la FAQ ).
En fait, ça me gêne d'entendre dire "les indices de tableaux peuvent être négatifs", car un tableau commence clairement à l'indice 0, mais ne sont en eux pas négatifs.
Cependant, dans la mesure ou tab[x] <=> *(tab + x)
Alors rien n'empeche de faire l'exemple que tu as fait.
Cependant, il faut savoir ce qu'on fait quand on fait ça.
Quoiqu'il en soit, size_t est un nombre positif (ou nul), et un tableau, dans l'absolu, commence toujours à l'indice 0, et ses indices par la suite sont positifs.
@InfernoLeZéro > désolé, j'avais fait une erreur, corrigé
Tient au passage, avec le ménage qui à été fait sur cette FAQ certains liens du 1er post ne pointent plus aux bonnes adresses (l'url est presque correcte mais ne pointe plus vers la bonne page, c'est les "p1","p2", etc qui posent problèmes). Ce serait bien de rectifier cela ...
D'accord pour les liens morts. Si tu pouvais me dire quels liens sont concernés, ou au moins m'aiguiller en me donnant une plage de numéros à contrôller, ça m'aiderait.
J'ai déménagé sur Zeste de savoir — Ex-manager des modérateurs.
Pour reprendre un point (du sujet sur la FAQ), et faire mon pédant :
Citation : ZéroZéroHuit-008
Désolé de polluer la FAQ
Si tu as des propositions, vas voir ici, je ne suis pas un spécialiste de size_t, et j'ai justement posté cette question parce que moi-même cherchais à l'utiliser convenablement.
Donc si tu as des améliorations/rectifications à donner, n'hésite pas, je puis à tout moment éditer le post
Citation : Pouet_forever
Il n'est défini que dans <stddef.h> qui est lui-même inclus par <stdio.h> et compagnie.
Je le sais, mais ça simplifie de l'exprimer ainsi même si ce n'est pas totalement vrai (mais pas totalement faux non-plus).
Hum, de ce que j'en sais, la norme ne définit rien en termes d'inclusion ; donc dans l'absolu, on ne sait pas qui inclut qui, ou s'ils s'incluent tout court. Par contre, effectivement, ta définition de size_t par les typedef est erronée, comme l'a dit Pouet_forever. J'avais pas fait gaffe quand j'avais parcouru ce topic, effectivement...
Hum, de ce que j'en sais, la norme ne définit rien en termes d'inclusion ; donc dans l'absolu, on ne sait pas qui inclut qui, ou s'ils s'incluent tout court. Par contre, effectivement, ta définition de size_t par les typedef est erronée, comme l'a dit Pouet_forever. J'avais pas fait gaffe quand j'avais parcouru ce topic, effectivement...
Je vais me renseigner un peu plus là-dessus et rectifier l'histoire du typedef
Par contre, size_t semble bien défini dans stddef.h, lui même inclut dans les autres... (enfin je n'ai pas très bien saisie ce que tu as voulu dire ).
En fait, je me suis trompé, et je m'excuse.
D'après la norme, size_t est bien défini dans stdio.h, stdlib.h, string.h et stddef.h.
On a aussi :
Citation : Norme C
The types used for size_t and ptrdiff_t should not have an integer conversion rank greater than that of signed long int unless the implementation supports objects large enough to make this necessary.
Ça voudrait dire qu'il ne peut prendre une valeur plus grande que le 'long int', ou je suis décidément très moyen en anglais ? Et par conséquent qu'il serait défini par ce dernier avec typedef ?
Hum, de ce que j'en sais, la norme ne définit rien en termes d'inclusion ; donc dans l'absolu, on ne sait pas qui inclut qui, ou s'ils s'incluent tout court. Par contre, effectivement, ta définition de size_t par les typedef est erronée, comme l'a dit Pouet_forever. J'avais pas fait gaffe quand j'avais parcouru ce topic, effectivement...
Je vais me renseigner un peu plus là-dessus et rectifier l'histoire du typedef
Par contre, size_t semble bien défini dans stddef.h, lui même inclut dans les autres... (enfin je n'ai pas très bien saisie ce que tu as voulu dire ).
Ce que je disais, c'est qu'il ne faut pas regarder dans les en-têtes pour savoir comment sont faites les choses. L'intérêt des normes, et du C portable, c'est qu'on a la garantie (plus ou moins, disons :-') que c'est partout pareil, peu importe dans le détail après comment le système se débrouille pour le faire (et qui est reflété par les en-têtes que tu lis).
Donc si j'ai bien compris, c'est dire qu'inclure ces fichiers permet d'utiliser 'size_t' puisqu'il est inclut d'une manière ou d'une autre par leur intermédiaire.
Sinon j'ai modifié l'histoire de la définition, quoique je ne pense pas que ce soit encore parfaitement correct. Cependant, après une recherche, 'size_t' est le type du résultat de sizeof mais est le plus souvent défini sur les systèmes par un typedef...
et enfin, *compar est un pointeur sur une fonction de comparaison que l'on fournit a qsort().
La fonction de comparaison sert a déterminer l'ordre du tri. Elle renvoie -1 si le premier élément doit précèder le second, 1 si le second élément doit précéder le premier et 0 si les éléments sont équivalents.
Exemple d'utilisation :
#include <stdio.h>
#include <stdlib.h>
/* fonction d'affichage */
void affiche (int tab[], unsigned sz)
{
unsigned i;
for (i = 0; i < sz; i++)
printf("%d ", tab[i]);
printf("\n");
}
/* fonction de comparaison pour tri en ordre croissant */
int comp(const void *a, const void *b)
{
const int *pa = a;
const int *pb = b;
return *pa > *pb ? 1 : *pa < *pb ? -1 : 0;
}
/* fonction de comparaison pour tri en ordre decroissant */
int comp_dec(const void *a, const void *b)
{
const int *pa = a;
const int *pb = b;
return *pa < *pb ? 1 : *pa > *pb ? -1 : 0;
}
int main(void)
{
int t[10] = { 143, 17, 271, 503, 648, 219, 38, 190, 145, 100 };
qsort(t, 10, sizeof(int), comp);
affiche (t, 10);
qsort(t, 10, sizeof(int), comp_dec);
affiche (t, 10);
return 0;
}
On évitera généralement une fonction de comparaison du genre return*pa-*pb; à cause du risque d'overflow.
Dans le cas d'un tri de chaines de caractères, la fonction strcmp() (définie dans string.h) est tout indiquée pour comparer.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html