éternel débutant en C pour mon plaisir, je me permets de venir vous
demander quelques éclaircissements sur une situation que je n'arrive pas
à comprendre :
J'utilise le cours en ligne spécial "grand débutant" du "site du zéro" :
<http://www.siteduzero.com/tutoriel-3-14189-apprenez-a-programmer-en-c.html>
Je réalise les exercices du cours dans deux environnements différents :
- sous windows vista avec l'IDE visual C++ 2008 express
- sous linux ubuntu 9.04 avec gcc
J'ai écrit un programme dans le cadre des exercices proposés sur les
tableaux par ce cours en ligne. Le fichier en question peut être
téléchargé ici :
< http://dl.free.fr/to7PFReLM/tableau.c>
Ce qui m'étonne, c'est que j'arrive à compiler sans difficulté ce code
sous Linux, et que le programme se comporte exactement comme je le
souhaite. Par contre, sous Windows, impossible de compiler, l'IDE me
renvoie 42 erreurs et 31 avertissements !!! La plupart des erreurs
semblent être liées aux variables. Par exemple :
"erreur de syntaxe : absence de ';' avant 'type'"
"identificateur non déclaré"
Or, j'ai beau lire et relire mon code, les variables me sembles toutes
déclarées correctement et il ne manque à mon sens pas de ";" en fin
d'instructions. De plus, comme je le disais au début, le même code se
compile sans aucune erreur sous Linux ...
Alors, comment expliquer que deux compilateurs réagissent aussi
différemment, et où et mon erreur ?
Merci par avance du temps que vous pourrez me consacrer,
Je n'ai pas affecté de valeur à a avant de l'utiliser.
Et justement, c'est pas interdit ça ?
Non, il ne me semble pas. En revanche prendre l'adresse d'une variable change son statut, d'une certaine façon.
-- Pierre Maurette
espie
In article <4aae45dd$0$440$, candide wrote:
Marc Espie a écrit :
Non, tout le monde ne comprend pas la notion d'infini. Ca n'est vraiment pas simple.
Mais je ne te parle pas de l'infini mathématique, l'infini dénombrable, non dénombrable, l'hypothèse du continu, etc. Je parle de l'infini de Monsieur tout le monde. Cet infini, ipso facto, est une abstraction puisque tout notre environnement (notre vie, nos frères, nos soeurs, les saisons, les jours, etc) est constitué d'éléments finis.
Mais alors tu parles de quel infini, au juste ? parce que le mien, c'est celui de la calculabilite et du probleme de l'arret et de tous ces trucs indecidables en informatique. Desole si je considere qu'il est relativement central a ce qu'on fait faire a nos cheres machines...
C'est ca qu'on entend, cote informatique, lorsqu'on parle d'abstraction. Pas juste un truc en passant, mais toutes les consequences qui vont avec. Et c'est pas si simple! faire abstraction de la memoire physique pour un modele abstrait, j'en connais qui ont du mal: t'as jamais eu des etudiants qui te demandent la valeur d'un pointeur donne ? ou comment les choses sont organisees en memoire "pour de vrai" ? ou qui ne *croient* pas aux fonctions recursives ? (impossible d'implementer un truc infini pour eux).
La notion de nombre abstrait est quelque chose d'a peu pres raisonnable. Quoique, en japonais par exemple, on ne compte pas pareil les gens, les objets longs, et les bols de riz. La notion de couleur n'est pas une notion raisonnable: toujours au Japon, tu as un seul mot qui designe le vert ET le bleu: aoi. (on peut exceptionnellement utiliser midori pour "la verdure", mais c'est plus "la couleur de la vegetation qu'une vraie distinction vert/bleu). Ca ne saute pas reellement aux yeux, jusqu'au moment ou on voit des feux verts japonais qui ont l'air tres, tres bleu a nos yeux d'occidentaux !
In article <4aae45dd$0$440$426a34cc@news.free.fr>,
candide <candide@free.invalid> wrote:
Marc Espie a écrit :
Non, tout le monde ne comprend pas la notion d'infini. Ca n'est vraiment
pas simple.
Mais je ne te parle pas de l'infini mathématique, l'infini dénombrable, non
dénombrable, l'hypothèse du continu, etc. Je parle de l'infini de Monsieur tout
le monde. Cet infini, ipso facto, est une abstraction puisque tout notre
environnement (notre vie, nos frères, nos soeurs, les saisons, les jours, etc)
est constitué d'éléments finis.
Mais alors tu parles de quel infini, au juste ?
parce que le mien, c'est celui de la calculabilite et du probleme de l'arret
et de tous ces trucs indecidables en informatique. Desole si je considere
qu'il est relativement central a ce qu'on fait faire a nos cheres machines...
C'est ca qu'on entend, cote informatique, lorsqu'on parle d'abstraction.
Pas juste un truc en passant, mais toutes les consequences qui vont avec.
Et c'est pas si simple! faire abstraction de la memoire physique pour un
modele abstrait, j'en connais qui ont du mal: t'as jamais eu des etudiants
qui te demandent la valeur d'un pointeur donne ? ou comment les choses
sont organisees en memoire "pour de vrai" ? ou qui ne *croient* pas aux
fonctions recursives ? (impossible d'implementer un truc infini pour eux).
La notion de nombre abstrait est quelque chose d'a peu pres raisonnable.
Quoique, en japonais par exemple, on ne compte pas pareil les gens, les
objets longs, et les bols de riz. La notion de couleur n'est pas une notion
raisonnable: toujours au Japon, tu as un seul mot qui designe le vert ET le
bleu: aoi. (on peut exceptionnellement utiliser midori pour "la verdure", mais
c'est plus "la couleur de la vegetation qu'une vraie distinction vert/bleu).
Ca ne saute pas reellement aux yeux, jusqu'au moment ou on voit des feux verts
japonais qui ont l'air tres, tres bleu a nos yeux d'occidentaux !
Non, tout le monde ne comprend pas la notion d'infini. Ca n'est vraiment pas simple.
Mais je ne te parle pas de l'infini mathématique, l'infini dénombrable, non dénombrable, l'hypothèse du continu, etc. Je parle de l'infini de Monsieur tout le monde. Cet infini, ipso facto, est une abstraction puisque tout notre environnement (notre vie, nos frères, nos soeurs, les saisons, les jours, etc) est constitué d'éléments finis.
Mais alors tu parles de quel infini, au juste ? parce que le mien, c'est celui de la calculabilite et du probleme de l'arret et de tous ces trucs indecidables en informatique. Desole si je considere qu'il est relativement central a ce qu'on fait faire a nos cheres machines...
C'est ca qu'on entend, cote informatique, lorsqu'on parle d'abstraction. Pas juste un truc en passant, mais toutes les consequences qui vont avec. Et c'est pas si simple! faire abstraction de la memoire physique pour un modele abstrait, j'en connais qui ont du mal: t'as jamais eu des etudiants qui te demandent la valeur d'un pointeur donne ? ou comment les choses sont organisees en memoire "pour de vrai" ? ou qui ne *croient* pas aux fonctions recursives ? (impossible d'implementer un truc infini pour eux).
La notion de nombre abstrait est quelque chose d'a peu pres raisonnable. Quoique, en japonais par exemple, on ne compte pas pareil les gens, les objets longs, et les bols de riz. La notion de couleur n'est pas une notion raisonnable: toujours au Japon, tu as un seul mot qui designe le vert ET le bleu: aoi. (on peut exceptionnellement utiliser midori pour "la verdure", mais c'est plus "la couleur de la vegetation qu'une vraie distinction vert/bleu). Ca ne saute pas reellement aux yeux, jusqu'au moment ou on voit des feux verts japonais qui ont l'air tres, tres bleu a nos yeux d'occidentaux !
Pierre Maurette
Marc Espie, le 14/09/2009 a écrit :
In article , Pierre Maurette wrote:
Bien entendu le problème est que sans typedef le int* p contient un piège: int* p, q, r;
Mais je préfère ce dommage collatéral à l'écriture int *p pour déclarer p comme pointeur vers int. On va éventuellement édicter la règle de style de ne déclarer qu'un pointeur par ligne, ou de passer par un typedef.
J'ai repondu a Gaby tongue-in-cheek que c'etait un usage C++.
Je vais preciser: c'est a mon avis NOCIF d'enseigner aux etudiants d'ecrire int* p; pour declarer un pointeur *EN C*.
Ca ne correspond aux usages habituels. Lorsqu'ils vont tomber sur du vrai code, ils vont etre surpris. Ils vont prendre des habitudes qui vont a l'encontre des usages industriels habituels.
Oui, ca se discute de savoir si la tradition est mieux ou pas. Mais bon, si je forme des programmeurs C, je ne vais pas commencer a foutre le bordel en leur apprenant a faire du C++....
Je suis convaincu par l'argument "a l'encontre des usages industriels habituels", qui par rapport au reste de la conversation me semble solide. A ce moment-là, proposer à vos ouailles "d'entendre" /char étoile s/, s est un /char étoile/, et leur passer votre conseil d'écriture. J'avais parlé de mnémotechnique dans un autre message et omis d'en parler. Vous écrivez comme vous pensez que c'est bien, mais vous déplacez l'étoile. Ainsi, s est un /char étoile/, et *s est un char. Ça devient intéresssant avec char **s, s est un char** (bof), *s est un char* (ah, une chaine...), etc.
-- Pierre Maurette
Marc Espie, le 14/09/2009 a écrit :
In article <mn.73da7d994f4c3f2b.79899@wanadoo.fr>,
Pierre Maurette <maurettepierre@wanadoo.fr> wrote:
Bien entendu le problème est que sans typedef le int* p contient un
piège:
int* p, q, r;
Mais je préfère ce dommage collatéral à l'écriture int *p pour déclarer
p comme pointeur vers int. On va éventuellement édicter la règle de
style de ne déclarer qu'un pointeur par ligne, ou de passer par un
typedef.
J'ai repondu a Gaby tongue-in-cheek que c'etait un usage C++.
Je vais preciser: c'est a mon avis NOCIF d'enseigner aux etudiants d'ecrire
int* p; pour declarer un pointeur *EN C*.
Ca ne correspond aux usages habituels. Lorsqu'ils vont tomber sur du vrai
code, ils vont etre surpris. Ils vont prendre des habitudes qui vont a
l'encontre des usages industriels habituels.
Oui, ca se discute de savoir si la tradition est mieux ou pas. Mais bon,
si je forme des programmeurs C, je ne vais pas commencer a foutre le bordel
en leur apprenant a faire du C++....
Je suis convaincu par l'argument "a l'encontre des usages industriels
habituels", qui par rapport au reste de la conversation me semble
solide. A ce moment-là, proposer à vos ouailles "d'entendre" /char
étoile s/, s est un /char étoile/, et leur passer votre conseil
d'écriture.
J'avais parlé de mnémotechnique dans un autre message et omis d'en
parler. Vous écrivez comme vous pensez que c'est bien, mais vous
déplacez l'étoile. Ainsi, s est un /char étoile/, et *s est un char. Ça
devient intéresssant avec char **s, s est un char** (bof), *s est un
char* (ah, une chaine...), etc.
Bien entendu le problème est que sans typedef le int* p contient un piège: int* p, q, r;
Mais je préfère ce dommage collatéral à l'écriture int *p pour déclarer p comme pointeur vers int. On va éventuellement édicter la règle de style de ne déclarer qu'un pointeur par ligne, ou de passer par un typedef.
J'ai repondu a Gaby tongue-in-cheek que c'etait un usage C++.
Je vais preciser: c'est a mon avis NOCIF d'enseigner aux etudiants d'ecrire int* p; pour declarer un pointeur *EN C*.
Ca ne correspond aux usages habituels. Lorsqu'ils vont tomber sur du vrai code, ils vont etre surpris. Ils vont prendre des habitudes qui vont a l'encontre des usages industriels habituels.
Oui, ca se discute de savoir si la tradition est mieux ou pas. Mais bon, si je forme des programmeurs C, je ne vais pas commencer a foutre le bordel en leur apprenant a faire du C++....
Je suis convaincu par l'argument "a l'encontre des usages industriels habituels", qui par rapport au reste de la conversation me semble solide. A ce moment-là, proposer à vos ouailles "d'entendre" /char étoile s/, s est un /char étoile/, et leur passer votre conseil d'écriture. J'avais parlé de mnémotechnique dans un autre message et omis d'en parler. Vous écrivez comme vous pensez que c'est bien, mais vous déplacez l'étoile. Ainsi, s est un /char étoile/, et *s est un char. Ça devient intéresssant avec char **s, s est un char** (bof), *s est un char* (ah, une chaine...), etc.
-- Pierre Maurette
Stephane Legras-Decussy
"Pierre Maurette" a écrit dans le message de news:
. On va éventuellement édicter la règle de style de ne déclarer qu'un pointeur par ligne, ou de passer par un typedef.
pour moi le typedef c'est exclusivement pour cacher struct, sinon c'est de l'obfuscation...
"Pierre Maurette" <maurettepierre@wanadoo.fr> a écrit dans le message de
news: mn.73da7d994f4c3f2b.79899@wanadoo.fr...
. On va éventuellement édicter la règle de style de ne déclarer qu'un
pointeur par ligne, ou de passer par un typedef.
pour moi le typedef c'est exclusivement
pour cacher struct, sinon c'est de l'obfuscation...
"Pierre Maurette" a écrit dans le message de news:
. On va éventuellement édicter la règle de style de ne déclarer qu'un pointeur par ligne, ou de passer par un typedef.
pour moi le typedef c'est exclusivement pour cacher struct, sinon c'est de l'obfuscation...
Manuel Pégourié-Gonnard
Francois scripsit:
Manuel Pégourié-Gonnard a écrit :
C'est ce qui me chifonne avec l'explication de Marc, citée en début de message : pour moi, la conclusion n'est pas que c'est le même opérateur (l'un sert à construire des types dérivés, l'autre à déréférencer) mais que c'est compréhensible de vouloir utiliser la même notation pour ces deux opérateurs différents.
Je ne comprends le "déréférencer" ? Construire des "types dérivées", j'imagine que c'est pour int *p; mais je ne comprends pas l'expression "déréférencer" dans ce que tu as dit.
Je veux parler de l'opération qui donne accès au contenu sur lequel pointe le pointeur. Par exemple dans "a = *p;" la variable "a" reçoit la valeur pointée par "p", et non pas la valeur de "p" lui-même.
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Francois scripsit:
Manuel Pégourié-Gonnard a écrit :
C'est ce qui me chifonne avec l'explication de Marc, citée en début de
message : pour moi, la conclusion n'est pas que c'est le même opérateur
(l'un sert à construire des types dérivés, l'autre à déréférencer) mais
que c'est compréhensible de vouloir utiliser la même notation pour ces
deux opérateurs différents.
Je ne comprends le "déréférencer" ?
Construire des "types dérivées", j'imagine que c'est pour
int *p; mais je ne comprends pas l'expression "déréférencer"
dans ce que tu as dit.
Je veux parler de l'opération qui donne accès au contenu sur lequel
pointe le pointeur. Par exemple dans "a = *p;" la variable "a" reçoit la
valeur pointée par "p", et non pas la valeur de "p" lui-même.
--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
C'est ce qui me chifonne avec l'explication de Marc, citée en début de message : pour moi, la conclusion n'est pas que c'est le même opérateur (l'un sert à construire des types dérivés, l'autre à déréférencer) mais que c'est compréhensible de vouloir utiliser la même notation pour ces deux opérateurs différents.
Je ne comprends le "déréférencer" ? Construire des "types dérivées", j'imagine que c'est pour int *p; mais je ne comprends pas l'expression "déréférencer" dans ce que tu as dit.
Je veux parler de l'opération qui donne accès au contenu sur lequel pointe le pointeur. Par exemple dans "a = *p;" la variable "a" reçoit la valeur pointée par "p", et non pas la valeur de "p" lui-même.
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Manuel Pégourié-Gonnard
Marc Espie scripsit:
Je vais preciser: c'est a mon avis NOCIF d'enseigner aux etudiants d'ecrire int* p; pour declarer un pointeur *EN C*.
Ca ne correspond aux usages habituels. Lorsqu'ils vont tomber sur du vrai code, ils vont etre surpris. Ils vont prendre des habitudes qui vont a l'encontre des usages industriels habituels.
Oui, ca se discute de savoir si la tradition est mieux ou pas. Mais bon, si je forme des programmeurs C, je ne vais pas commencer a foutre le bordel en leur apprenant a faire du C++....
Personnellement, je trouve "int* p" ou "int * p" plus compréhensible sur le principe. Après, on en revient à ce que tu disais plus haut, les expressions idiomatiques, et on peut trouver à titre personnel que "int* p" est plus clair tout en lisant et écrivant "int *p" parce qu'on sait bien que c'est l'usage dominant et qu'on ne va pas penser à chaque détail de ce qu'on lit ou écrit, mais voir le tout d'un coup.
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Marc Espie scripsit:
Je vais preciser: c'est a mon avis NOCIF d'enseigner aux etudiants d'ecrire
int* p; pour declarer un pointeur *EN C*.
Ca ne correspond aux usages habituels. Lorsqu'ils vont tomber sur du vrai
code, ils vont etre surpris. Ils vont prendre des habitudes qui vont a
l'encontre des usages industriels habituels.
Oui, ca se discute de savoir si la tradition est mieux ou pas. Mais bon,
si je forme des programmeurs C, je ne vais pas commencer a foutre le bordel
en leur apprenant a faire du C++....
Personnellement, je trouve "int* p" ou "int * p" plus compréhensible sur
le principe. Après, on en revient à ce que tu disais plus haut, les
expressions idiomatiques, et on peut trouver à titre personnel que
"int* p" est plus clair tout en lisant et écrivant "int *p" parce qu'on
sait bien que c'est l'usage dominant et qu'on ne va pas penser à chaque
détail de ce qu'on lit ou écrit, mais voir le tout d'un coup.
--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Je vais preciser: c'est a mon avis NOCIF d'enseigner aux etudiants d'ecrire int* p; pour declarer un pointeur *EN C*.
Ca ne correspond aux usages habituels. Lorsqu'ils vont tomber sur du vrai code, ils vont etre surpris. Ils vont prendre des habitudes qui vont a l'encontre des usages industriels habituels.
Oui, ca se discute de savoir si la tradition est mieux ou pas. Mais bon, si je forme des programmeurs C, je ne vais pas commencer a foutre le bordel en leur apprenant a faire du C++....
Personnellement, je trouve "int* p" ou "int * p" plus compréhensible sur le principe. Après, on en revient à ce que tu disais plus haut, les expressions idiomatiques, et on peut trouver à titre personnel que "int* p" est plus clair tout en lisant et écrivant "int *p" parce qu'on sait bien que c'est l'usage dominant et qu'on ne va pas penser à chaque détail de ce qu'on lit ou écrit, mais voir le tout d'un coup.
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Stephane Legras-Decussy
"candide" a écrit dans le message de news: 4aae34d2$0$7787$
OK mais ça c'est autre chose, toi tu parles de programmer un GUI (genre GTK) mais là on s'éloigne de l'apprentissage du C. Tu peux faire un peu de programmation graphique pour apprendre à utiliser une bibliothèque non standard sans faire de programmation événementielle (ou alors très limitée) parce que sinon tu vas rentrer dans des détails qui n'ont plus rien à voir avec l'apprentissage du C.
oui, perso j'ai autodidacté le C en 1989 avec le Borland turbo C.... c'était excellent avec le tout simple graphics.h qui permettait des trucs superbes en 640x480 16 couleurs...
"candide" <candide@free.invalid> a écrit dans le message de news:
4aae34d2$0$7787$426a74cc@news.free.fr...
OK mais ça c'est autre chose, toi tu parles de programmer un GUI (genre
GTK)
mais là on s'éloigne de l'apprentissage du C. Tu peux faire un peu de
programmation graphique pour apprendre à utiliser une bibliothèque non
standard
sans faire de programmation événementielle (ou alors très limitée) parce
que
sinon tu vas rentrer dans des détails qui n'ont plus rien à voir avec
l'apprentissage du C.
oui, perso j'ai autodidacté le C en 1989
avec le Borland turbo C.... c'était excellent
avec le tout simple graphics.h qui permettait
des trucs superbes en 640x480 16 couleurs...
"candide" a écrit dans le message de news: 4aae34d2$0$7787$
OK mais ça c'est autre chose, toi tu parles de programmer un GUI (genre GTK) mais là on s'éloigne de l'apprentissage du C. Tu peux faire un peu de programmation graphique pour apprendre à utiliser une bibliothèque non standard sans faire de programmation événementielle (ou alors très limitée) parce que sinon tu vas rentrer dans des détails qui n'ont plus rien à voir avec l'apprentissage du C.
oui, perso j'ai autodidacté le C en 1989 avec le Borland turbo C.... c'était excellent avec le tout simple graphics.h qui permettait des trucs superbes en 640x480 16 couleurs...
Francois
Manuel Pégourié-Gonnard a écrit :
Je veux parler de l'opération qui donne accès au contenu sur lequel pointe le pointeur. Par exemple dans "a = *p;" la variable "a" reçoit la valeur pointée par "p", et non pas la valeur de "p" lui-même.
D'accord, mais dans ce cas, j'ai dû mal à comprendre pourquoi tu dis qu'il y a deux opérateurs "*". Enfin, je comprends mais je ne trouve pas que ce soit la façon la plus simple de voir les choses.
Pour moi, comme le disait Marc, je trouve plus simple de dire qu'avec "int *p;", *p représente une variable de type int (modulo une gestion de la mémoire différente c'est vrai).
Dans "a = *p;" on fait comme si *p était une variable de type int. Dans "*p = 30;", pareil. Après, la variable *p n'a pas la même signification (valeur ou zone mémoire) suivant qu'elle est à droite ou à gauche du symbole "=", mais cette nuance, finalement, on la retrouve absolument à l'identique avec une variable dite "classique" : dans "var = 30;" et "x = var;", var n'a pas la même signification (valeur ou zone mémoire).
Bon après, je suis loin, très très loin d'être aussi calé que tous les intervenants ici présents. Disons que c'est comme ça que j'ai compris les pointeurs.
-- François Lafont
Manuel Pégourié-Gonnard a écrit :
Je veux parler de l'opération qui donne accès au contenu sur lequel
pointe le pointeur. Par exemple dans "a = *p;" la variable "a" reçoit la
valeur pointée par "p", et non pas la valeur de "p" lui-même.
D'accord, mais dans ce cas, j'ai dû mal à comprendre
pourquoi tu dis qu'il y a deux opérateurs "*". Enfin, je
comprends mais je ne trouve pas que ce soit la façon la plus
simple de voir les choses.
Pour moi, comme le disait Marc, je trouve plus simple de
dire qu'avec "int *p;", *p représente une variable de type
int (modulo une gestion de la mémoire différente c'est vrai).
Dans "a = *p;" on fait comme si *p était une variable de
type int. Dans "*p = 30;", pareil. Après, la variable *p n'a
pas la même signification (valeur ou zone mémoire) suivant
qu'elle est à droite ou à gauche du symbole "=", mais cette
nuance, finalement, on la retrouve absolument à l'identique
avec une variable dite "classique" : dans "var = 30;" et "x
= var;", var n'a pas la même signification (valeur ou zone
mémoire).
Bon après, je suis loin, très très loin d'être aussi calé
que tous les intervenants ici présents. Disons que c'est
comme ça que j'ai compris les pointeurs.
Je veux parler de l'opération qui donne accès au contenu sur lequel pointe le pointeur. Par exemple dans "a = *p;" la variable "a" reçoit la valeur pointée par "p", et non pas la valeur de "p" lui-même.
D'accord, mais dans ce cas, j'ai dû mal à comprendre pourquoi tu dis qu'il y a deux opérateurs "*". Enfin, je comprends mais je ne trouve pas que ce soit la façon la plus simple de voir les choses.
Pour moi, comme le disait Marc, je trouve plus simple de dire qu'avec "int *p;", *p représente une variable de type int (modulo une gestion de la mémoire différente c'est vrai).
Dans "a = *p;" on fait comme si *p était une variable de type int. Dans "*p = 30;", pareil. Après, la variable *p n'a pas la même signification (valeur ou zone mémoire) suivant qu'elle est à droite ou à gauche du symbole "=", mais cette nuance, finalement, on la retrouve absolument à l'identique avec une variable dite "classique" : dans "var = 30;" et "x = var;", var n'a pas la même signification (valeur ou zone mémoire).
Bon après, je suis loin, très très loin d'être aussi calé que tous les intervenants ici présents. Disons que c'est comme ça que j'ai compris les pointeurs.
-- François Lafont
Pierre Maurette
Stephane Legras-Decussy, le 14/09/2009 a écrit :
"candide" a écrit dans le message de news: 4aae34d2$0$7787$
OK mais ça c'est autre chose, toi tu parles de programmer un GUI (genre GTK) mais là on s'éloigne de l'apprentissage du C. Tu peux faire un peu de programmation graphique pour apprendre à utiliser une bibliothèque non standard sans faire de programmation événementielle (ou alors très limitée) parce que sinon tu vas rentrer dans des détails qui n'ont plus rien à voir avec l'apprentissage du C.
oui, perso j'ai autodidacté le C en 1989 avec le Borland turbo C.... c'était excellent avec le tout simple graphics.h qui permettait des trucs superbes en 640x480 16 couleurs...
Il était encore très bien quelques années plus tard. Les deux défauts dont je me souvienne: l'idée que cet EDI donnait que le C c'était le C Borland avec ses bibliothèques, et les raccourcis d'éditions. Il y a quelques jours j'ai cherché pour mes Linux un éditeur qui ressemble à ça, je n'ai rien trouvé.
-- Pierre Maurette
Stephane Legras-Decussy, le 14/09/2009 a écrit :
"candide" <candide@free.invalid> a écrit dans le message de news:
4aae34d2$0$7787$426a74cc@news.free.fr...
OK mais ça c'est autre chose, toi tu parles de programmer un GUI (genre
GTK)
mais là on s'éloigne de l'apprentissage du C. Tu peux faire un peu de
programmation graphique pour apprendre à utiliser une bibliothèque non
standard
sans faire de programmation événementielle (ou alors très limitée) parce
que
sinon tu vas rentrer dans des détails qui n'ont plus rien à voir avec
l'apprentissage du C.
oui, perso j'ai autodidacté le C en 1989
avec le Borland turbo C.... c'était excellent
avec le tout simple graphics.h qui permettait
des trucs superbes en 640x480 16 couleurs...
Il était encore très bien quelques années plus tard. Les deux défauts
dont je me souvienne: l'idée que cet EDI donnait que le C c'était le C
Borland avec ses bibliothèques, et les raccourcis d'éditions.
Il y a quelques jours j'ai cherché pour mes Linux un éditeur qui
ressemble à ça, je n'ai rien trouvé.
"candide" a écrit dans le message de news: 4aae34d2$0$7787$
OK mais ça c'est autre chose, toi tu parles de programmer un GUI (genre GTK) mais là on s'éloigne de l'apprentissage du C. Tu peux faire un peu de programmation graphique pour apprendre à utiliser une bibliothèque non standard sans faire de programmation événementielle (ou alors très limitée) parce que sinon tu vas rentrer dans des détails qui n'ont plus rien à voir avec l'apprentissage du C.
oui, perso j'ai autodidacté le C en 1989 avec le Borland turbo C.... c'était excellent avec le tout simple graphics.h qui permettait des trucs superbes en 640x480 16 couleurs...
Il était encore très bien quelques années plus tard. Les deux défauts dont je me souvienne: l'idée que cet EDI donnait que le C c'était le C Borland avec ses bibliothèques, et les raccourcis d'éditions. Il y a quelques jours j'ai cherché pour mes Linux un éditeur qui ressemble à ça, je n'ai rien trouvé.
-- Pierre Maurette
Mickaël Wolff
Stephane Legras-Decussy wrote:
"Pierre Maurette" a écrit dans le message de news:
. On va éventuellement édicter la règle de style de ne déclarer qu'un pointeur par ligne, ou de passer par un typedef.
pour moi le typedef c'est exclusivement pour cacher struct, sinon c'est de l'obfuscation...
C'est vrai que les types pointeurs sur fonction facilitent la lecture, sans typedef ;)
