Différence de résultat entre compilateurs

candide

12/09/2009 à 14:32

-ed- a écrit :

décevant (mode console...). Je pense qu'une phase intermédiaire
(Pyhthon, par exemple) permettrait d'acquérir rapidement les principes
de bases dans la programmation (valeurs, variables, opérateurs,
fonctions, décision, itérations, etc.) sans plonger le nez dans les
détails scabreux du C qui existent par ce que c'est le plus bas des
langages de haut niveau.

Tout à fait d'accord.

Dans la mesure où, en C, on sait pas passer un tableau à une fonction,
les pointeurs sont indispensable dès que les données d'un tableau
doivent être traitées (remplissage, tri, affichage etc.).

Non, les pointeurs ne sont absolument pas indispensables pour ça (remplir un
tableau, trier un tableau, afficher un tableau, même un tableau 2D)

Ce qui est troublant en C, c'est que, pour un paramètre,, les syntaxes
T *a et T a[] sont équivalentes :

f(T *a) ou f(T a[])

Ah exactement le genre de truc qu'il faut dire à un débutant ! Que ces syntaxes
soient équivalentes est totalement anecdotique et n'a AUCUNE implication
pratique, c'est quelque chose qui ne sert quasiment jamais sauf à essayer
d'impressionner à peu de frais les newbies.

Stephane Legras-Decussy

13/09/2009 à 01:44

"Marc Boyer" a écrit dans le message de
news: h8di13$tba$

C'est en effet un problème: dans une promo classique,
il y a 20% qui comprend du premier coup (et à du mal à
comprendre que les autres puissent ne pas comprendre),
et les autres.
Que fait-on des autres ?

peut etre un changement dans l'approche...
j'ai toujours vu le prof : bon maintenant on va aborder
les pointeurs... froncement de sourcil, regards inquiets
des étudiants...

le truc ce serait de commencer par ça.... 1ère heure :

le C : les types, les variables, les pointeurs, les adresses...

le reste du C aux cours suivants...

-ed-

13/09/2009 à 10:52

On 12 sep, 11:14, ""
wrote:

Je pense avoir acquis les principes de base avec un site :
"algorithmes pour non-matheux" fait par un prof de Jussieux. Je suis
intéressé par python mais je considère C en premier parce que on pe ut
faire appel à C dans d'autres langages alors que on ne peut pas faire
appel à d'autres langage dans C et il semble que C est à la base et
que c'est un langage qui se compile rapidement.

Alors tu n'est pas un simple comptable; Tu es un comptable avec une
formation basique d'informaticien, c'est pas pareil. Ceci dit, il
n'empêche que l'usage du C impose de connaitre un certains nombres de
détails spécifiques à ce langage (il y a notamment un certains nombre
de pièges dans les fonctions de saisie), qui fait que son usage
fiable, même pour un programmeur confirmé, est loin d'être trivial.

Par contre, l'argument "se compile rapidement" est étrange. Python se
'compile' encore plus rapidement, vu qu'il est interprété (0
compilation !). Tu veux peut être dire qu'il s'exécute plus
rapidement, oui, c'est certainement vrai, si le code est ben écrit. En
C, on a une meilleure maitrise des performances. Après, c'est
l'expérience du programmeur qui fait la différence.

A vrai dire, je vous "rentre dedans" avec mon sentiment vis-à-vis des
pointeurs. C'est volontaire. Mon point de vue sera d'éviter de faire
appel aux pointeurs quand c'est possible quand je code.

Quand aux pointeurs, rien qu'en C++, il existe une manière simple de
les cacher partiellement (notamment lors des appels de fonction): les
références (ce qui n'existe pas, pour le moment, en C... des projets
secrets seraient à l'étude ...), mais quand on fait de l'allocation
dynamique, il faut bien placer le résultat de l'allocation (l'adresse
de la variable allouée) dans une variable contenant une adresse. Or, à
part un pointeur, je ne vois pas comment faire autrement... C'est donc
incontournable. Après,on peut discuter sur l'utilité de l'allocation
dynamique. Dans certains langages (Python etc.), elle ne se voit pas
et est entièrement prise en charge par le langage à l'exécution... Ça
pose alors des problèmes de performance et d'optimisation. En C, on
maitrise tout au byte près. Évidemment, c'est plus difficile, comme il
est plus difficile de régler sa voiture soi même que de considérer qu e
c'est une simple machine exécutant le service qu'on lui demande...

Cependant, je crois comprendre que pour les fonctions ils n'y a pas
beaucoup d'alternatives notamment quand il faut passer les arguments
par valeur ou adresse. C'est ça que je dois comprendre quand tu
dis ..."la seule façon de contenir une adresse est d'utiliser une
variable de type pointeur".

Pour une variable dont on veut modifier la valeur, non, il n'y a pas
d'autre choix en C que de passer explicitement son adresse. Or la
seule façon de passer une adresse à une fonction est d'utiliser un
paramètre capable de recevoir une adresse, c'est à dire un pointeur.

Il n'y a pas une alternative possible à l'exposé ci-dessous (que j'ai
compilé des différents ouvrages et tutoriel bien que je n'ai pas
encore commencé avec le chapitre des fonctions) :

void PERMUTER (int A, int B)
{
int AIDE;
AIDE = A;
A = B;
B = AIDE;

}

Nous appelons la fonction pour deux variables X et Y par:

int main(void)

int x, y ;

printf("Enter 2 integers : ") ;

scanf("%d %d", &x, &y) ;

Ce qui est marrant, c'est la solution est donnée ici... D'où
l'absurdité d'introduire les fonctions de saisies avant la maitrise
des fonctions et des pointeurs...

Pour illustrer le propose, il suffisait de 2 valeurs en dur
différentes :

int x = 1;
int y = 2;

PERMUTER(X, Y);

Attention, le C est sensible à la casse x et X sont des
identificateurs différents.

printf("nRslt : x : %dt y : %d ", x, y ) ;

Est-il logique de placer le marque de fin de ligne ... au début de
celle-ci ? A quoi sert l'espace en fin de ligne ? Attention, l'effet
produit par un t n'est pas portable...

printf("Rslt : x : %d y : %dn", x, y ) ;

Résultat: X et Y restent inchangés !

Oui, normal, on a transmis une copie de la valeur et non l'adresse de
la variable. La valeur initiale reste inchangée.

void PERMUTER (int *A, int *B)
{
int AIDE;
AIDE = *A;
*A = *B;
*B = AIDE;

}

AIDE est un nom curieux. En général, on dit 'temporaire' (ou temp,
tmp ...) ou éventuellement, 'relais' . Le bon usage des
identificateurs aide à l'auto-documentation du code qui permet le plus
souvent de se passer de commentaire (ou de les réserver aux points
délicats).

Nous appelons la fonction par:

PERMUTER(&X, &Y);

Résultat: Le contenu des variables X et Y est échangé !

Oui, il n'y a pas d'alternative, de la manière dont sont définies x et
y. As-tu compris ce que signifiait & dans ce contexte ?

Question sans rapport avec ci-dessus :

J'ai lu une critique du langage pascal de Kernighan, et il dit que la
phase de compilation de pascal se fait du bas vers le haut et que les
fonctions doivent être définies après la procédure principale (je ne
connais pas ce langage alors je ne suis pas sûre des termes). Alors
que le C se compile du haut vers le bas.

C'est un peu n'importe quoi... Le Pascal se compile en une passe, donc
du haut vers le bas. Tout (variable, fonctions) doit être défini avant
usage (ce qui me parait logique). En C, c'est pareil...

Je crois comprendre qu'un informaticien de formation et même d'autres
métiers apprennent le langage pascal ou ont une initiation pour une
intro à la programmation.

Oui, c'était une pratique courante dans les années 80/90,
malheureusement en perte de vitesse. Je le regrette, car la rigueur du
Pascal (notamment de sa version la plus courante : Turbo Pascal ou
Freepascal, car le Pascal standard et quasiment inutilisable, pas d'E/
S, ce qui devrait plaire à candide), permettait d'acquérir une grande
rigueur dans sa façon de programmer, ce qui est tout le contraire avec
les langages à la mode comme Python etc.).

Alors pourquoi en C, ca marche sous windows (gcc - djgpp) il me semble
mais pas sous linux (gcc) on ne peut pas déclarer :

int n ;
int Tableau[n] ;

déjà, si n n'apas de valeur définie, ce code ne peut pas compiler,
même en C99, ensuite, il ya plusieurs versions du C, les 3 principales
étant :

- Le C original (dit K&R) définit en 1973 par le livre Le langage C
par Kernighan et Ritchie (1ère édition).
- Le C standard 89/90 définit en 1989 par l'ANSI et repris tel quel en
1990 par l'ISO
- Le C standard 99 définit en 1999 par l'ISO

Le C 99 introduit de nouveaux concepts comme les VLA (Variable Length
Array), qui permettent (dans certaines conditions) d'écrire :

int n = 123;
int Tableau[n] ;

A ma connaissance, gcc ne supporte toujours pas correctement les
VLA...

gcc 4.4 : http://gcc.gnu.org/gcc-4.4/c99status.html : Broken !

comme tu le vois, le C , c'est pas si simple...

Le fait que C compile du haut vers le bas devrait favoriser ce genre
de déclaration ?

Aucun rapport. De toutes façons, le C est compilé du haut vers le pas
(peut être bien en 2 passes, je ne sais pas trop...)

On 12 sep, 11:14, "bpascal...@googlemail.com"
<bpascal...@googlemail.com> wrote:

Je pense avoir acquis les principes de base avec un site :
"algorithmes pour non-matheux" fait par un prof de Jussieux. Je suis
intéressé par python mais je considère C en premier parce que on pe ut
faire appel à C dans d'autres langages alors que on ne peut pas faire
appel à d'autres langage dans C et il semble que C est à la base et
que c'est un langage qui se compile rapidement.

Alors tu n'est pas un simple comptable; Tu es un comptable avec une
formation basique d'informaticien, c'est pas pareil. Ceci dit, il
n'empêche que l'usage du C impose de connaitre un certains nombres de
détails spécifiques à ce langage (il y a notamment un certains nombre
de pièges dans les fonctions de saisie), qui fait que son usage
fiable, même pour un programmeur confirmé, est loin d'être trivial.

Par contre, l'argument "se compile rapidement" est étrange. Python se
'compile' encore plus rapidement, vu qu'il est interprété (0
compilation !). Tu veux peut être dire qu'il s'exécute plus
rapidement, oui, c'est certainement vrai, si le code est ben écrit. En
C, on a une meilleure maitrise des performances. Après, c'est
l'expérience du programmeur qui fait la différence.

A vrai dire, je vous "rentre dedans" avec mon sentiment vis-à-vis des
pointeurs. C'est volontaire. Mon point de vue sera d'éviter de faire
appel aux pointeurs quand c'est possible quand je code.

Quand aux pointeurs, rien qu'en C++, il existe une manière simple de
les cacher partiellement (notamment lors des appels de fonction): les
références (ce qui n'existe pas, pour le moment, en C... des projets
secrets seraient à l'étude ...), mais quand on fait de l'allocation
dynamique, il faut bien placer le résultat de l'allocation (l'adresse
de la variable allouée) dans une variable contenant une adresse. Or, à
part un pointeur, je ne vois pas comment faire autrement... C'est donc
incontournable. Après,on peut discuter sur l'utilité de l'allocation
dynamique. Dans certains langages (Python etc.), elle ne se voit pas
et est entièrement prise en charge par le langage à l'exécution... Ça
pose alors des problèmes de performance et d'optimisation. En C, on
maitrise tout au byte près. Évidemment, c'est plus difficile, comme il
est plus difficile de régler sa voiture soi même que de considérer qu e
c'est une simple machine exécutant le service qu'on lui demande...

Cependant, je crois comprendre que pour les fonctions ils n'y a pas
beaucoup d'alternatives notamment quand il faut passer les arguments
par valeur ou adresse. C'est ça que je dois comprendre quand tu
dis ..."la seule façon de contenir une adresse est d'utiliser une
variable de type pointeur".

Pour une variable dont on veut modifier la valeur, non, il n'y a pas
d'autre choix en C que de passer explicitement son adresse. Or la
seule façon de passer une adresse à une fonction est d'utiliser un
paramètre capable de recevoir une adresse, c'est à dire un pointeur.

Il n'y a pas une alternative possible à l'exposé ci-dessous (que j'ai
compilé des différents ouvrages et tutoriel bien que je n'ai pas
encore commencé avec le chapitre des fonctions) :

void PERMUTER (int A, int B)
{
int AIDE;
AIDE = A;
A = B;
B = AIDE;

}

Nous appelons la fonction pour deux variables X et Y par:

int main(void)

int x, y ;

printf("Enter 2 integers : ") ;

scanf("%d %d", &x, &y) ;

Ce qui est marrant, c'est la solution est donnée ici... D'où
l'absurdité d'introduire les fonctions de saisies avant la maitrise
des fonctions et des pointeurs...

Pour illustrer le propose, il suffisait de 2 valeurs en dur
différentes :

int x = 1;
int y = 2;

PERMUTER(X, Y);

Attention, le C est sensible à la casse x et X sont des
identificateurs différents.

printf("nRslt : x : %dt y : %d ", x, y ) ;

Est-il logique de placer le marque de fin de ligne ... au début de
celle-ci ? A quoi sert l'espace en fin de ligne ? Attention, l'effet
produit par un t n'est pas portable...

printf("Rslt : x : %d y : %dn", x, y ) ;

Résultat: X et Y restent inchangés !

Oui, normal, on a transmis une copie de la valeur et non l'adresse de
la variable. La valeur initiale reste inchangée.

void PERMUTER (int *A, int *B)
{
int AIDE;
AIDE = *A;
*A = *B;
*B = AIDE;

}

AIDE est un nom curieux. En général, on dit 'temporaire' (ou temp,
tmp ...) ou éventuellement, 'relais' . Le bon usage des
identificateurs aide à l'auto-documentation du code qui permet le plus
souvent de se passer de commentaire (ou de les réserver aux points
délicats).

Nous appelons la fonction par:

PERMUTER(&X, &Y);

Résultat: Le contenu des variables X et Y est échangé !

Oui, il n'y a pas d'alternative, de la manière dont sont définies x et
y. As-tu compris ce que signifiait & dans ce contexte ?

Question sans rapport avec ci-dessus :

J'ai lu une critique du langage pascal de Kernighan, et il dit que la
phase de compilation de pascal se fait du bas vers le haut et que les
fonctions doivent être définies après la procédure principale (je ne
connais pas ce langage alors je ne suis pas sûre des termes). Alors
que le C se compile du haut vers le bas.

C'est un peu n'importe quoi... Le Pascal se compile en une passe, donc
du haut vers le bas. Tout (variable, fonctions) doit être défini avant
usage (ce qui me parait logique). En C, c'est pareil...

Je crois comprendre qu'un informaticien de formation et même d'autres
métiers apprennent le langage pascal ou ont une initiation pour une
intro à la programmation.

Oui, c'était une pratique courante dans les années 80/90,
malheureusement en perte de vitesse. Je le regrette, car la rigueur du
Pascal (notamment de sa version la plus courante : Turbo Pascal ou
Freepascal, car le Pascal standard et quasiment inutilisable, pas d'E/
S, ce qui devrait plaire à candide), permettait d'acquérir une grande
rigueur dans sa façon de programmer, ce qui est tout le contraire avec
les langages à la mode comme Python etc.).

Alors pourquoi en C, ca marche sous windows (gcc - djgpp) il me semble
mais pas sous linux (gcc) on ne peut pas déclarer :

int n ;
int Tableau[n] ;

déjà, si n n'apas de valeur définie, ce code ne peut pas compiler,
même en C99, ensuite, il ya plusieurs versions du C, les 3 principales
étant :

- Le C original (dit K&R) définit en 1973 par le livre Le langage C
par Kernighan et Ritchie (1ère édition).
- Le C standard 89/90 définit en 1989 par l'ANSI et repris tel quel en
1990 par l'ISO
- Le C standard 99 définit en 1999 par l'ISO

Le C 99 introduit de nouveaux concepts comme les VLA (Variable Length
Array), qui permettent (dans certaines conditions) d'écrire :

int n = 123;
int Tableau[n] ;

A ma connaissance, gcc ne supporte toujours pas correctement les
VLA...

gcc 4.4 : http://gcc.gnu.org/gcc-4.4/c99status.html : Broken !

comme tu le vois, le C , c'est pas si simple...

Le fait que C compile du haut vers le bas devrait favoriser ce genre
de déclaration ?

Aucun rapport. De toutes façons, le C est compilé du haut vers le pas
(peut être bien en 2 passes, je ne sais pas trop...)

Vous avez filtré cet utilisateur ! Consultez son message

On 12 sep, 11:14, ""
wrote:

Je pense avoir acquis les principes de base avec un site :
"algorithmes pour non-matheux" fait par un prof de Jussieux. Je suis
intéressé par python mais je considère C en premier parce que on pe ut
faire appel à C dans d'autres langages alors que on ne peut pas faire
appel à d'autres langage dans C et il semble que C est à la base et
que c'est un langage qui se compile rapidement.

Alors tu n'est pas un simple comptable; Tu es un comptable avec une
formation basique d'informaticien, c'est pas pareil. Ceci dit, il
n'empêche que l'usage du C impose de connaitre un certains nombres de
détails spécifiques à ce langage (il y a notamment un certains nombre
de pièges dans les fonctions de saisie), qui fait que son usage
fiable, même pour un programmeur confirmé, est loin d'être trivial.

Par contre, l'argument "se compile rapidement" est étrange. Python se
'compile' encore plus rapidement, vu qu'il est interprété (0
compilation !). Tu veux peut être dire qu'il s'exécute plus
rapidement, oui, c'est certainement vrai, si le code est ben écrit. En
C, on a une meilleure maitrise des performances. Après, c'est
l'expérience du programmeur qui fait la différence.

A vrai dire, je vous "rentre dedans" avec mon sentiment vis-à-vis des
pointeurs. C'est volontaire. Mon point de vue sera d'éviter de faire
appel aux pointeurs quand c'est possible quand je code.

Quand aux pointeurs, rien qu'en C++, il existe une manière simple de
les cacher partiellement (notamment lors des appels de fonction): les
références (ce qui n'existe pas, pour le moment, en C... des projets
secrets seraient à l'étude ...), mais quand on fait de l'allocation
dynamique, il faut bien placer le résultat de l'allocation (l'adresse
de la variable allouée) dans une variable contenant une adresse. Or, à
part un pointeur, je ne vois pas comment faire autrement... C'est donc
incontournable. Après,on peut discuter sur l'utilité de l'allocation
dynamique. Dans certains langages (Python etc.), elle ne se voit pas
et est entièrement prise en charge par le langage à l'exécution... Ça
pose alors des problèmes de performance et d'optimisation. En C, on
maitrise tout au byte près. Évidemment, c'est plus difficile, comme il
est plus difficile de régler sa voiture soi même que de considérer qu e
c'est une simple machine exécutant le service qu'on lui demande...

Cependant, je crois comprendre que pour les fonctions ils n'y a pas
beaucoup d'alternatives notamment quand il faut passer les arguments
par valeur ou adresse. C'est ça que je dois comprendre quand tu
dis ..."la seule façon de contenir une adresse est d'utiliser une
variable de type pointeur".

Pour une variable dont on veut modifier la valeur, non, il n'y a pas
d'autre choix en C que de passer explicitement son adresse. Or la
seule façon de passer une adresse à une fonction est d'utiliser un
paramètre capable de recevoir une adresse, c'est à dire un pointeur.

Il n'y a pas une alternative possible à l'exposé ci-dessous (que j'ai
compilé des différents ouvrages et tutoriel bien que je n'ai pas
encore commencé avec le chapitre des fonctions) :

void PERMUTER (int A, int B)
{
int AIDE;
AIDE = A;
A = B;
B = AIDE;

}

Nous appelons la fonction pour deux variables X et Y par:

int main(void)

int x, y ;

printf("Enter 2 integers : ") ;

scanf("%d %d", &x, &y) ;

Ce qui est marrant, c'est la solution est donnée ici... D'où
l'absurdité d'introduire les fonctions de saisies avant la maitrise
des fonctions et des pointeurs...

Pour illustrer le propose, il suffisait de 2 valeurs en dur
différentes :

int x = 1;
int y = 2;

PERMUTER(X, Y);

Attention, le C est sensible à la casse x et X sont des
identificateurs différents.

printf("nRslt : x : %dt y : %d ", x, y ) ;

Est-il logique de placer le marque de fin de ligne ... au début de
celle-ci ? A quoi sert l'espace en fin de ligne ? Attention, l'effet
produit par un t n'est pas portable...

printf("Rslt : x : %d y : %dn", x, y ) ;

Résultat: X et Y restent inchangés !

Oui, normal, on a transmis une copie de la valeur et non l'adresse de
la variable. La valeur initiale reste inchangée.

void PERMUTER (int *A, int *B)
{
int AIDE;
AIDE = *A;
*A = *B;
*B = AIDE;

}

AIDE est un nom curieux. En général, on dit 'temporaire' (ou temp,
tmp ...) ou éventuellement, 'relais' . Le bon usage des
identificateurs aide à l'auto-documentation du code qui permet le plus
souvent de se passer de commentaire (ou de les réserver aux points
délicats).

Nous appelons la fonction par:

PERMUTER(&X, &Y);

Résultat: Le contenu des variables X et Y est échangé !

Oui, il n'y a pas d'alternative, de la manière dont sont définies x et
y. As-tu compris ce que signifiait & dans ce contexte ?

Question sans rapport avec ci-dessus :

J'ai lu une critique du langage pascal de Kernighan, et il dit que la
phase de compilation de pascal se fait du bas vers le haut et que les
fonctions doivent être définies après la procédure principale (je ne
connais pas ce langage alors je ne suis pas sûre des termes). Alors
que le C se compile du haut vers le bas.

C'est un peu n'importe quoi... Le Pascal se compile en une passe, donc
du haut vers le bas. Tout (variable, fonctions) doit être défini avant
usage (ce qui me parait logique). En C, c'est pareil...

Je crois comprendre qu'un informaticien de formation et même d'autres
métiers apprennent le langage pascal ou ont une initiation pour une
intro à la programmation.

Oui, c'était une pratique courante dans les années 80/90,
malheureusement en perte de vitesse. Je le regrette, car la rigueur du
Pascal (notamment de sa version la plus courante : Turbo Pascal ou
Freepascal, car le Pascal standard et quasiment inutilisable, pas d'E/
S, ce qui devrait plaire à candide), permettait d'acquérir une grande
rigueur dans sa façon de programmer, ce qui est tout le contraire avec
les langages à la mode comme Python etc.).

Alors pourquoi en C, ca marche sous windows (gcc - djgpp) il me semble
mais pas sous linux (gcc) on ne peut pas déclarer :

int n ;
int Tableau[n] ;

déjà, si n n'apas de valeur définie, ce code ne peut pas compiler,
même en C99, ensuite, il ya plusieurs versions du C, les 3 principales
étant :

- Le C original (dit K&R) définit en 1973 par le livre Le langage C
par Kernighan et Ritchie (1ère édition).
- Le C standard 89/90 définit en 1989 par l'ANSI et repris tel quel en
1990 par l'ISO
- Le C standard 99 définit en 1999 par l'ISO

Le C 99 introduit de nouveaux concepts comme les VLA (Variable Length
Array), qui permettent (dans certaines conditions) d'écrire :

int n = 123;
int Tableau[n] ;

A ma connaissance, gcc ne supporte toujours pas correctement les
VLA...

gcc 4.4 : http://gcc.gnu.org/gcc-4.4/c99status.html : Broken !

comme tu le vois, le C , c'est pas si simple...

Le fait que C compile du haut vers le bas devrait favoriser ce genre
de déclaration ?

Aucun rapport. De toutes façons, le C est compilé du haut vers le pas
(peut être bien en 2 passes, je ne sais pas trop...)

-ed-

13/09/2009 à 10:57

On 12 sep, 11:20, ""
wrote:

J'avais oublié dans le post précédent ; on ne peut pas définir de s
paramètres avec des valeurs qui seront échangées autrement qu'en
déclarant des pointeurs?

Non. On peut utiliser la forme [] pour définir les paramètres (déjà
expliqué dans un post précédent), mais techniquement ça reste des
pointeurs. Si la vrai question est "peut-on appeler cette fonction
autrement qu'avec des &", la réponse est oui. C'est notamment le cas
si on échange des éléments d'un tableau

int tab[3] = {1,2,3};

/* echanger les elements 0 et 2 du tableau */
echange (tab + 0, tab + 2);

donne :

3 2 1

-ed-

13/09/2009 à 11:05

On 12 sep, 14:32, candide wrote:

> Dans la mesure où, en C, on ne sait pas passer un tableau à une fon ction,
> les pointeurs sont indispensable dès que les données d'un tableau
> doivent être traitées (remplissage, tri, affichage etc.).

Non, les pointeurs ne sont absolument pas indispensables pour ça (rempl ir un
tableau, trier un tableau, afficher un tableau, même un tableau 2D)

Pour traiter les données d'un tableau dans une fonction ?

int a[] = {1,2,3};
int b[] = {4,5,6,7};

afficher (a, 3);
afficher (b, 4);

peux-tu indiquer le codage de afficher() sans pointeurs, ça
m'intéresse...

> Ce qui est troublant en C, c'est que, pour un paramètre,, les syntaxe s
> T *a et T a[] sont équivalentes :

> f(T *a) ou f(T a[])

Ah exactement le genre de truc qu'il faut dire à un débutant ! Que ces syntaxes
soient équivalentes est totalement anecdotique et n'a AUCUNE implicatio n
pratique, c'est quelque chose qui ne sert quasiment jamais <...>

Je pense qu'il vaut mieux le dire rapidement, car on peut tomber
dessus par hasard, ce qui peut provoquer des réactions bizarres, dans
le genre "vous voyez bien qu'on peut passer des tableaux à une
fonction"...

-ed-

13/09/2009 à 11:06

On 13 sep, 01:44, "Stephane Legras-Decussy" wrote:

"Marc Boyer" a écrit dans le message denews: h8di13$tb__BEGIN_MASK_n#9g02mG7!__...__END_MASK_i?a63jfAD$ .cict.fr...

> C'est en effet un problème: dans une promo classique,
> il y a 20% qui comprend du premier coup (et à du mal à
> comprendre que les autres puissent ne pas comprendre),
> et les autres.
> Que fait-on des autres ?

peut etre un changement dans l'approche...
j'ai toujours vu le prof : bon maintenant on va aborder
les pointeurs... froncement de sourcil, regards inquiets
des étudiants...

le truc ce serait de commencer par ça.... 1ère heure :

le C : les types, les variables, les pointeurs, les adresses...

le reste du C aux cours suivants...

Ou commencer par l'assembleur ... C'est pas si difficile...

-ed-

13/09/2009 à 11:12

On 13 sep, 10:52, -ed- wrote:

> A vrai dire, je vous "rentre dedans" avec mon sentiment vis-à-vis des
> pointeurs. C'est volontaire. Mon point de vue sera d'éviter de faire
> appel aux pointeurs quand c'est possible quand je code.

Quand aux pointeurs, rien qu'en C++, il existe une manière simple de

Je suis tombé là-dessus ce matin:

http://fr.web-2-site.net/content/grand-d%C3%A9calage-entre-universit%C3%A9- et-r%C3%A9alit%C3%A9

intéressant sujet de réflexion...

-ed-

13/09/2009 à 11:16

On 13 sep, 11:12, -ed- wrote:

On 13 sep, 10:52, -ed- wrote:

> > A vrai dire, je vous "rentre dedans" avec mon sentiment vis-à-vis d es
> > pointeurs. C'est volontaire. Mon point de vue sera d'éviter de fair e
> > appel aux pointeurs quand c'est possible quand je code.

> Quand aux pointeurs, rien qu'en C++, il existe une manière simple de

Je suis tombé là-dessus ce matin:

http://fr.web-2-site.net/content/grand-d%C3%A9calage-entre-universit%...

intéressant sujet de réflexion...

Encore plus intéressant, l'article original et les commentaires :

http://www.vinch.be/blog/2009/09/12/le-grand-decalage-entre-universite-et-r ealite/

Pierre Maurette

13/09/2009 à 11:18

-ed-, le 13/09/2009 a écrit :

On 13 sep, 10:52, -ed- wrote:
A vrai dire, je vous "rentre dedans" avec mon sentiment vis-à-vis des
pointeurs. C'est volontaire. Mon point de vue sera d'éviter de faire
appel aux pointeurs quand c'est possible quand je code.

Quand aux pointeurs, rien qu'en C++, il existe une manière simple de

Je suis tombé là-dessus ce matin:

http://fr.web-2-site.net/content/grand-d%C3%A9calage-entre-universit%C3%A9-et-r%C3%A9alit%C3%A9

intéressant sujet de réflexion...

Lien amusant surtout dans Firefox et Opera (Windows et Linux)...

--
Pierre Maurette

espie

13/09/2009 à 12:25

In article ,
wrote:

A vrai dire, je vous "rentre dedans" avec mon sentiment vis-à-vis des
pointeurs. C'est volontaire. Mon point de vue sera d'éviter de faire
appel aux pointeurs quand c'est possible quand je code.
Cependant, je crois comprendre que pour les fonctions ils n'y a pas
beaucoup d'alternatives notamment quand il faut passer les arguments
par valeur ou adresse. C'est ça que je dois comprendre quand tu
dis ..."la seule façon de contenir une adresse est d'utiliser une
variable de type pointeur".

Sans pointeur, il y a juste des trucs que tu ne pourras pas faire. C'est
un mal necessaire des que tu dois gerer des structures de donnees de taille
non fixee a l'avance (oui, il y a bien les tableaux de taille variable en C99,
mais c'est loin de remplacer tous les usages des pointeurs).

Des que tu vas vouloir jouer avec des chaines de caracteres, tu es oblige
d'utiliser des pointeurs... c'est un choix delibere du langage.

Si tu es *refractaire* aux pointeurs, passe ton chemin ! change de langage !
oublie le C avant qu'il ne soit trop tard !

Différence de résultat entre compilateurs

10 réponses

Veuillez sélectionner un problème