Quelques précisions. . .

Citation:

---

Envoyé par Array

1-. S'il n'y avait pas pas de structures en C, serais-ce un handicap, où pourrions-nous facilement nous-en passer?

---

Ce serait un handicap sur le plan des performances. Pourquoi cette question ?

Citation:

---

Dans quelle situation une structure peut-elle s'avérer indispensable (écartez celle où l'on veut améliorer l'aspect du code).

---

Pour écrire du code performant, réutilisable et bien organisé. Mais c'est vrai qu'on peut s'en passer...

Citation:

---

2-. Une structure peut-elle contribuer à rendre un programme plus rapide?

---

Oui.

Citation:

---

3-. Sur le site d'Emmanuel, il y a ce code :

Code:

---

1 2 3 4 5 6 7

size_t i; for (i = 0; i < N; i++) { free(pp[i]), pp[i] = NULL; } free(pp), pp = NULL;

---

Je me demandais simplement pourquoi utilise-t-on une virgule à la place d'un point-virgule? Est-ce pour une raison particulière, ou par souci d'esthétisme?

---

Pas pour une raison technique, car le ';' aurait eu le même effet (ici).

C'est pour une question d'organisation du code. Je considère que la séquence free(p) p=NULL doit être en quelque sorte 'une et indivisible'. Ce n'est évidemment qu'une vue de l'esprit, mais je trouve important que ça se voit.

En effet, tel que le code est présenté, il est peu probable que l'on cherche à insérer du code entre ces deux instructions (ce qui serait un risque erreur).

D'autre par, un indenteur automatique comme GNUIndent 1.91 respecte la ligne formée par des instructions séparée par des virgules, ce qui n'est évidemment pas le cas d'instructions séparées par un ';' qui se retrouvent évidemment à la ligne suivante.

Bonjour,

Sachez que je tiens à vous remercier pour vos deux réponses précédentes...

J'aurais une *autre* question...
J'aimerais savoir pourquoi le code suivant est considéré comme une erreur :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

#include <stdio.h>   struct world { int x; int y; int z; } typedef struct world world_t;   int func(world_t value) { printf("%d\n", value.x); return value.x; }   int main(void) { func(1024); return 0; }

---

Les types sont incompatibles...
Pourquoi?

P.S.: Soyez compréhensifs, je ne suis qu'à la deuxième page sur le chapitre des structures...

Remerciements,

Sincèrement,

Array

Ta fonction demande qu'on lui passe en paramètre une valeur de type world_t et tu lui passes un entier (int, unsigned, long, short, char, etc.)...

Une structure n'est pas un entier et un entier n'est pas une structure...

Pour te le dire de façon imagée, c'est comme mettre des fourchettes dans un presse-agrume... C'est juste... Pas fait pour ça.

Salut,

Code:

---

1 2 3 4 5

struct world { int x; int y; int z; }

---

Il manque le point-virgule après la déclaration de ta structure.

Code:

---

1 2 3 4 5 6 7 8 9

int func(world_t value) { printf("%d\n", value.x); return value.x; }   int main(void) { func(1024); return 0; }

---

Que cherches-tu à faire avec ce code ?
Tu envoies la constante 1024 (donc un nombre entier) en paramètre à la fonction func, mais celle-ci attend un type world_t : il y a donc incompatibilité entre ces deux types (1024 n'a pas d'attribut x !).

Pour envoyer une structure world_t, tu dois d'abord déclarer une variable de ce type dans la fonction main, et tu pourras ensuite la passer par paramètre à la fonction func.
Attention, quand tu déclares une variable de type world_t, par exemple :

Code:

---

world_t a;

---

Les attributs de la variable a (c'est à dire a.x, a.y et a.z) ne sont pas définis. N'oublie pas de leur attribuer une valeur avant de les lire.

Citation:

---

Envoyé par Haze.

Attention, quand tu déclares une variable de type world_t, par exemple :

Code:

---

world_t a;

---

Les attributs de la variable a (c'est à dire a.x, a.y et a.z) ne sont pas définis.

---

En C, on utilise pas le terme 'attribut' qui appartient plutôt aux classes des langages OO. On parle d'éléments[ de structures].

Citation:

---

Que cherches-tu à faire avec ce code ?

---

En fait, j'ai, dans un programme, une fonction ayant un prototype comme celui-ci (juste les noms que je donne diffèrent de la vraie fonction) :

Code:

---

1 2	int pdsSeek(size_t i, size_t j, int x, int y, int z, FILE *fp);

---

Dans le programme qui inclu cette fonction, les variables i, j, x, y, z, *fp sont UTILISÉS MASSIVEMENT.

Donc, dans les sources, j'ai plusieurs fonctions utilisant les même variables, mais cela sans structures...
Alors je me demandais si je ne searis pas mieux d'utiliser des structures pour optimizer mon code et centraliser les variables qui sont redondantes...

Que me suggérez-vous de faire?
Initialiser une structure dans main puis la passer dans les diverses fonctions?
Devrais-je déclarer des pointeurs de structures (accès avec ->) ou des variables du type de la structure (accès avec .)?

Merci,

Sincèrement,

Array

Citation:

---

Envoyé par Array

En fait, j'ai, dans un programme, une fonction ayant un prototype comme celui-ci (juste les noms que je donne diffèrent de la vraie fonction) :

Code:

---

1 2	int pdsSeek(size_t i, size_t j, int x, int y, int z, FILE *fp);

---

Dans le programme qui inclu cette fonction, les variables i, j, x, y, z, *fp sont UTILISÉS MASSIVEMENT.

Donc, dans les sources, j'ai plusieurs fonctions utilisant les même variables, mais cela sans structures...
Alors je me demandais si je ne searis pas mieux d'utiliser des structures pour optimizer mon code et centraliser les variables qui sont redondantes...

Que me suggérez-vous de faire?
Initialiser une structure dans main puis la passer dans les diverses fonctions?
Devrais-je déclarer des pointeurs de structures (accès avec ->) ou des variables du type de la structure (accès avec .)?

---

Attention à ne pas confondre les variables et les paramètres.

Si se sont des variables, elles doivent être définies dans la fonction :

Code:

---

1 2	int pdsSeek(FILE *fp);

---

avec

Code:

---

1 2 3 4

int pdsSeek(FILE *fp) { size_t i, size_t j, int x, int y, int z,

---

Tant que les variables sont locales, on peut les multiplier, ça n'a aucune importance. La notion de 'redondance' ne s'applique pas. Elles sont détruites en fin de fonction et l'espace est récupéré automatiquement (on les appelle aussi 'variables automatiques'). Leur portée est strictement limitée au bloc dans les quelles elles sont définies.

Par contre, si on a besoin de variables dont la durée de vie dépasse celle d'une fonction, il faut mettre en œuvre d'autres mécanisme, comme le passage de paramètre, voire de l'adresse de la variable (via un pointeur évidement) si celle-ci doit être modifiée par la fonction. Dès qu'il y a plus de 2 variables 'pointeurs', il faut probablement une ou des structures de données pour clarifier l'organisation et simplifier le codage.

Bonjour,

Voilà que je m'interroge sur... malloc().

J'aimerais savoir si malloc() alloue la mémoire de façon continue, c'est à dire que les "bytes" alloués par malloc() se suivent jusqu'à la fin...


Par exemple, si j'appelle malloc() de la façon suivante :

Code:

---

int *ptr = malloc(54);

---

Est-ce que, de (ptr) à (ptr+53), ce sera uniquement des bytes alloués par malloc()?

Je vous remercie,

Sincèrement,

Array

Oui

Citation:

---

Envoyé par Array

Bonjour,

Voilà que je m'interroge sur... malloc().

J'aimerais savoir si malloc() alloue la mémoire de façon continue, c'est à dire que les "bytes" alloués par malloc() se suivent jusqu'à la fin...

Je vous remercie,

Sincèrement,

Array

---

Il ne faut pas s'interroger. Il faut lire la doc. D'ailleurs malloc est utilisé pour créer dynamiquement un tableau donc évidemment la réponse est oui.

Je m'en doutais...

En effet, comment malloc aurait pu faire autrement?

Mais... enfin, passons...
J'ai simplement vu un schéma sur un site qui me faisait croire le contraire...

Citation:

---

Envoyé par Array

Par exemple, si j'appelle malloc() de la façon suivante :

Code:

---

int *ptr = malloc(54);

---

Est-ce que, de (ptr) à (ptr+53), ce sera uniquement des bytes alloués par malloc()?

---

Non ! malloc(54) de la mémoire pour 54 octets pas pour 54 ints. Sachant que la taille d'un int est sizeof(int), tu aurais du écrire :

Code:

---

int *ptr = malloc(54 * sizeof(int));

---

Et n'oublie pas que si p est un pointeur différent de void *, p + i vaut en fait &(p[i]) pas ce que tu penses.

Citation:

---

Envoyé par Array

Voilà que je m'interroge sur... malloc().

J'aimerais savoir si malloc() alloue la mémoire de façon continue, c'est à dire que les "bytes" alloués par malloc() se suivent jusqu'à la fin...

---

La réponse est dans ton livre de C.

C'est bien beau de se poser des questions, mais la réponse aux questions basiques est le plus souvent dans ton manuel. Il y a des références sur mon site.

Citation:

---

Envoyé par Array

J'ai simplement vu un schéma sur un site qui me faisait croire le contraire...

---

Donne la référence.

Citation:

---

La réponse est dans ton livre de C.

---

Justement, c'est pour cela que je pose la question.
malloc() est abordée dans le chapitre sur les pointeurs, mais on ne spécifie pas encore comment elle fonctionne...

Citation:

---

Donne la référence.

---

http://img183.imageshack.us/img183/5323/mallocyl1.png

J'ai juste enregistré l'image, je n'ai pas noté le site, j'en consulte tellement...

Citation:

---

Non ! malloc(54) de la mémoire pour 54 octets pas pour 54 ints

---

Oui, je sais, c'est l'erreur que j'ai fait antérieurement...
Cette fois-ci, ce n'était que pour allouer 54 chars (ou octets) dans la mémoire.


Une autre question pour finir la journée en beauté...

Voici ce code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

#include <stdio.h> #include <stdlib.h>   int main(void) { void *ptr; int i; ptr = &i; ptr++; return 0; }

---

GCC compile ce code parfaitement...

Mais ICC (Compilateur d'Intel), reporte cette erreur :

Code:

---

1 2 3 4 5 6 7 8 9

Intel(R) C++ Compiler for applications running on IA-32, Version 10.1 Build 20071116 Package ID: w_cc_p_10.1.013 Copyright (C) 1985-2007 Intel Corporation. All rights reserved.   main.c main.c(8): error: expression must be a pointer to a complete object type ptr++; ^

---

Où est l'erreur, comment la corriger!?
J'aimerais utiliser un code semblable parce que, dans une fonction, j'aimerais allouer un tableau à 4 dimensions utilisant des types ayant des tailles spécifiées en argument, et je retournerais un pointeur void* parce que le type du pointeur peut-être n'importe quoi...

De plus, quel type est recommandé pour contenir l'adresse que contient un pointeur? Est-ce mieux ptrdiff_t où size_t (on dit que ptrdiff_t est utilisé seulement lorsqu'il y a soustraction d'adresses mémoire, mais, je m'interroge malgré cela).

Que faire?


Merci,

Sincèrement,

Array

petite remarque : plutôt que de continuer indéfiniment une discussion (15 pages, c'est long...), ne pourrais-tu pas en créer de nouvelles ? Avantages que j'y vois :
1) pour une question précise, on voit tout de suite de quoi il s'agit et une personne qui se pose la même question le voit !
2) pour les questions vraiment basique, il sera plus facile pour les modérateurs de supprimer la discussion, si son archivage ne présente pas d'intérêt.
3) quand on veut essayer de répondre aux posts, lire tous les messages précédents est assez pénible

Voila, mais cela n'engage que moi ...

Citation:

---

Envoyé par Array

Justement, c'est pour cela que je pose la question.
malloc() est abordée dans le chapitre sur les pointeurs, mais on ne spécifie pas encore comment elle fonctionne...

---

Effectivement, dans le K&R2, cette information n'apparait pas clairement. Si tu as le moindre doute, tu peux toujours consulter un site de référence :

http://www.opengroup.org/onlinepubs/...ns/malloc.html

Citation:

---

http://img183.imageshack.us/img183/5323/mallocyl1.png

J'ai juste enregistré l'image, je n'ai pas noté le site, j'en consulte tellement...

---

Oui, cette image est extraite du K&R2, normalement, elle n'est pas libre de droit... Passons...

Elle fait partie du chapitre 8 dans un article qui décrit un allocateur mémoire (une implémentation de malloc() / free()). On explique que des allocations successives peuvent donner des blocs non contigus, ce qui est logique.

Citation:

---

Oui, je sais, c'est l'erreur que j'ai fait antérieurement...
Cette fois-ci, ce n'était que pour allouer 54 chars (ou octets) dans la mémoire.

---

Dans ce cas, il eut été logique que le pointeur fut de type char * ...

Citation:

---

Code:

---

1 2 3 4 5 6 7

int main(void) { void *ptr; int i; ptr = &i; ptr++; }

---

GCC compile ce code parfaitement...

Mais ICC (Compilateur d'Intel), reporte cette erreur :

Code:

---

1 2 3 4 5 6 7 8 9

Intel(R) C++ Compiler for applications running on IA-32, Version 10.1 Build 20071116 Package ID: w_cc_p_10.1.013 Copyright (C) 1985-2007 Intel Corporation. All rights reserved.   main.c main.c(8): error: expression must be a pointer to a complete object type ptr++; ^

---

Où est l'erreur, comment la corriger!?

---

L'erreur est de vouloir déréférencer un void*. C'est absurde, car, par-définition, on ne sait pas quel est le type pointé. Le compilateur Intel fait donc son travail en relevant l'erreur.

Le compilateur gcc en aurait fait de même si il avait été configuré en mode C (-ansi -pedantic)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

Project : Forums Compiler : GNU GCC Compiler (called directly) Directory : C:\dev\forums\ -------------------------------------------------------------------------------- Switching to target: default Compiling: main.c In file included from C:/CodeBlocks/include/stdio.h:26, from main.c:1: C:/CodeBlocks/include/stddef.h:6:2: warning: #include_next is a GCC extension In file included from C:/CodeBlocks/include/stdio.h:28, from main.c:1: C:/CodeBlocks/include/stdarg.h:6:2: warning: #include_next is a GCC extension In file included from main.c:1: C:/CodeBlocks/include/stdio.h:330: warning: ISO C90 does not support `long long' In file included from C:/CodeBlocks/include/stdlib.h:22, from main.c:2: C:/CodeBlocks/include/stddef.h:6:2: warning: #include_next is a GCC extension In file included from main.c:2: C:/CodeBlocks/include/stdlib.h:476: warning: ISO C90 does not support `long long' C:/CodeBlocks/include/stdlib.h:476: warning: ISO C90 does not support `long long' C:/CodeBlocks/include/stdlib.h:478: warning: ISO C90 does not support `long long' C:/CodeBlocks/include/stdlib.h:478: warning: ISO C90 does not support `long long' C:/CodeBlocks/include/stdlib.h:480: warning: ISO C90 does not support `long long' C:/CodeBlocks/include/stdlib.h:480: warning: ISO C90 does not support `long long' C:/CodeBlocks/include/stdlib.h:481: warning: ISO C90 does not support `long long' C:/CodeBlocks/include/stdlib.h:482: warning: ISO C90 does not support `long long' C:/CodeBlocks/include/stdlib.h:484: warning: ISO C90 does not support `long long' C:/CodeBlocks/include/stdlib.h:485: warning: ISO C90 does not support `long long' C:/CodeBlocks/include/stdlib.h:488: warning: ISO C90 does not support `long long' main.c: In function `main': main.c:9: warning: wrong type argument to increment Linking console executable: console.exe Process terminated with status 0 (0 minutes, 2 seconds) 0 errors, 16 warnings

---

et non GNUC, comme il est par défaut. En effet, en GNUC (un langage dérivé du C, conçu pour compiler le noyau et le modules GNU/Linux), l'arithmétique des pointeurs est autorisée sur un pointeur de type void. Il est alors traité comme un pointeur de type char. Personnellement, je n'aime pas beaucoup ce genre d'extension qui apporte plus de confusion qu'autre chose d'utile...

Citation:

---

J'aimerais utiliser un code semblable parce que, dans une fonction, j'aimerais allouer un tableau à 4 dimensions utilisant des types ayant des tailles spécifiées en argument, et je retournerais un pointeur void* parce que le type du pointeur peut-être n'importe quoi...

---

Dans ce cas, on utilise un pointeur local de type char (char *) initialisé avec la valeur de type void * passée en paramètre.

Citation:

---

De plus, quel type est recommandé pour contenir l'adresse que contient un pointeur?

---

Je ne comprends pas la question. Un pointeur contient déjà une adresse. Que veux-tu de plus ?

Citation:

---

Est-ce mieux ptrdiff_t où size_t (on dit que ptrdiff_t est utilisé seulement lorsqu'il y a soustraction d'adresses mémoire, mais, je m'interroge malgré cela).

---

http://emmanuel-delahaye.developpez....page=Page4#LXV

ptrdiff_t est utile pour les index calculés à partir d'une différence d'adresses d'un même objet (tableau, évidemment) et pour les index décroissants.

Citation:

---

Envoyé par corentin59

petite remarque : plutôt que de continuer indéfiniment une discussion (15 pages, c'est long...), ne pourrais-tu pas en créer de nouvelles ? Avantages que j'y vois :
1) pour une question précise, on voit tout de suite de quoi il s'agit et une personne qui se pose la même question le voit !
2) pour les questions vraiment basique, il sera plus facile pour les modérateurs de supprimer la discussion, si son archivage ne présente pas d'intérêt.
3) quand on veut essayer de répondre aux posts, lire tous les messages précédents est assez pénible

Voila, mais cela n'engage que moi ...

---

Je suis assez d'accord. Cette façon de s'approprier une discussion est finalement assez egoïste, car elle ne permet pas le partage facile d'information... Elle n'arrange finalement que le P.O. C'est contraire au principe d'un forum qui est censé être un lieu d'échange et de partage.

Le système de suivi des discussion par email est suffisant pour s'y retrouver, même si on a posé 20 questions éparses...

L'unité d'information sur un forum n'est pas Mr X ou Mr Y, mais un sujet précis au titre explicite.

Citation:

---

Envoyé par Array

Une autre question pour finir la journée en beauté ...
Voici ce code :

Code:

---

1 2 3 4 5 6 7 8 9 10

#include <stdio.h> #include <stdlib.h>   int main(void) { void *ptr; int i; ptr = &i; ptr++; return 0; }

---

GCC compile ce code parfaitement ...
Mais ICC (Compilateur d'Intel), reporte cette erreur : ...

---

On ne peut pas appliquer l'arithmétique des pointeurs aux pointeurs génériques car par exemple on ne sait pas comment évaleur p + i. Comme je te l'ai déjà dit p + 1 ne vaut pas p + 1 mais p + sizeof(char, int, long, etc. selon que p pointe sur un char, int ou long ...). Or un void * peut pointer sur n'importe quoi donc on ne sait pas de combien faut-il déplacer l'adresse pour atteindre l'objet suivant. GCC joue peut-être mieux avec les void *, mais pas forcément les autres compilateurs parce que ce n'est pas exigé par la norme.

Citation:

---

Envoyé par Array

J'aimerais utiliser un code semblable parce que, dans une fonction, j'aimerais allouer un tableau à 4 dimensions utilisant des types ayant des tailles spécifiées en argument, et je retournerais un pointeur void* parce que le type du pointeur peut-être n'importe quoi...

---

Pour faire de la programmation générique il faut savoir utiliser les fonctions génériques memcpy, memset et compagnie. Je sens encore que plutôt que d'aller lire la doc tu vas te précipiter à poser des questions sur ce thread qui devient effectivement trop long. Je t'invite à consulter mon site qui contient entre autres un tutorial d'initiation au langage C.

Citation:

---

Envoyé par Array

De plus, quel type est recommandé pour contenir l'adresse que contient un pointeur?

---

<type> * ou void *.

Citation:

---

Envoyé par Array

Est-ce mieux ptrdiff_t où size_t (on dit que ptrdiff_t est utilisé seulement lorsqu'il y a soustraction d'adresses mémoire, mais, je m'interroge malgré cela).

---

Selon l'implémentation sizeof peut retourner un entier signé ou non signé. Utiliser size_t permet d'écrire du code portable puisqu'on n'a pas à se soucier des détails de l'implémentation. Quant à ptrdiff_t, il est utilisé pour à peu près ls mêmes raisons que size_t, mais il est est défini comme étant le type retourné par la soustraction de deux pointeurs (qui doivent avoir le même type). A retenir également que (p + 1) - p vaut 1 et non sizeof(*p).

Citation:

---

Envoyé par Melem

Selon l'implémentation sizeof peut retourner un entier signé ou non signé.

---

Euh, non. La norme est claire : sizeof retourne un size_t qui est un entier non signé dimensionné de façon à pouvoir contenir la taille (en bytes) du plus grand objet possible dans une implémentation donnée.