Différence de résultat entre compilateurs

"bpascal123@googlemail.com" <bpascal123@googlemail.com> writes:

[...]

| Au sujet de livre, j'attends le K&R.
| En tant que comptable et non programmeur, est-ce que je peux attendre
| de la lecture de ce livre de progresser en C ou bien ça ne sera
| qu'une illusion? Je suppose que les auteurs ne l'ont pas écrit pour
| des comptables, c'est pourquoi je demande.

Si tu as déjà des notions de programmation, alors c'est un trà ¨s Bon
Investissement.

-- Gaby

<bpascal123@googlemail.com> a écrit dans le message de news:
422700e9-fc21-44c9-9318-

Au sujet de livre, j'attends le K&R.
En tant que comptable et non programmeur, est-ce que je peux attendre
de la lecture de ce livre de progresser en C ou bien ça ne sera
qu'une illusion?

très bon bouquin de référence mais
particulierement austère...

et il ne fait la distinction entre "ce qui sert"
et "ce qui ne sert pas"...

par exemple le débutant va dépenser une
quantité considérable d'énergie à digérer
scanf.... alors qu'on s'en fout de scanf...

de meme les macro... prévoir un carton
d'aspirine... alors qu'il suffit de ne pas s'en servir...

la lecture de la faq est une des meilleures choses à faire
pour faire un gros bond en C...

"candide" <candide@free.invalid> a écrit dans le message de news:
4aaa4a72$0$1570$426a74cc@news.free.fr...

. Bien sûr que stricto sensu, un pointeur c'est facile à comprendre
mais c'est un comme une histoire drôle dont tu comprends tous les mots et
qui ne
te fait pas rire.

et pourtant il suffit de programmer stricto sensu...

* keep It Simple & Stupid *

Si tu parles d' enc***lage au sens d'enc***lage de mouches, tu te trompes.
La
Norme s'intéresse autant au détail qu'aux questions fondamentales. La
Norme fait
des distinctions dans son exposition qui n'apparaissent pas dans les
exposés
traditionnels. La Norme a au moins la délicatesse et l'intelligence de
commencer
son exposé en donnant des définitions, relativement précises. La Norme
sépare la
syntaxe, les contraintes et la sémantique et une partie de la difficulté à
comprendre les pointeurs provient de la syntaxe des pointeurs. La Norme
t'aide
à comprendre qu'il faut un vocabulaire choisi pour parler sans ambiguïtén
(par
exemple, la Norme n'utilise pas le terme de "variable"). Bref, la Norme
n'est
pas un document réservé au programmeur chevronné, il s'adresse aussi à
ceux qui
veulent enseigner et/ou comprendre le C ou en tous cas, ça peut aider
certains à
mieux l'enseigner (je vous rassure, je n'enseigne pas le C).

ouf... on dirait un extrait de la norme ... :-)

Stephane Legras-Decussy a écrit :

très bon bouquin de référence mais

de référence ? certainement pas. C'est censé être un livre d'apprentissage. De
référence, ce serait Harbison and Steele mais pour moi c'est raté. La seule
référence, c'est la Norme.

particulierement austère...

et il ne fait la distinction entre "ce qui sert"
et "ce qui ne sert pas"...

Ce n'est pas du tout la question. Pratiquement tout ce dont ils parlent sert car
c'est censé être (et c'est) du basique.

par exemple le débutant va dépenser une
quantité considérable d'énergie à digérer
scanf.... alors qu'on s'en fout de scanf...

T'es sur que t'as lu le livre ? Il faut lui reconnaître cette qualité qu'il sait
épargner à ses lecteurs de cette infantilisation insupportable des programmes
pseudo-interactifs basés sur des scanf() systématiques (dans le K&R, pas un seul
scanf() avant le chapitre VII sur les E/S);

de meme les macro... prévoir un carton
d'aspirine... alors qu'il suffit de ne pas s'en servir...

Ben à l'époque (1988) probablement que les macros étaient d'un usage plus
répandus. Bon sinon, l'exposé sur les macros dans le K&R n'est pas un exposé
systématique ni écrasant, il n'y a d'ailleurs pas de chapitre particulier sur
cette question, tout juste moins de 4 pages (dernier § du chapitre 4). Dans mes
notes marginales, j'avais écrit lors de ma première lecture : "Beaucoup trop
court pour quelque chose d'aussi important et d'assez délicat". En ce qui me
concerne, j'avais trouvé l'exposé très peu clair.

la lecture de la faq est une des meilleures choses à faire
pour faire un gros bond en C...

Même après 2 ans d'apprentissage du C, il y a plein de question dont je
n'arrivais même pas à comprendre l'intérêt. J'avais trouvé la lecture des FAQ
(fclc, clc) très difficile (et en plus ça correspondait jamais aux question que
je me posais naturellement).

candide <candide@free.invalid> writes:

| Stephane Legras-Decussy a écrit :
|
| > très bon bouquin de référence mais
|
| de référence ? certainement pas. C'est censé être un livre d'apprentissage. De
| référence, ce serait Harbison and Steele mais pour moi c'est ra té. La seule
| référence, c'est la Norme.

K&R est un livre pour apprendre à écrire de bons programmes en C.

J'avais fait l'hypothèse que le posteur originel n'avait pas l'ambition
de rester « débutant » ; c'est pour cela que j'ai suggé ré le K&R.

Pour ceux qui poursuivent une vocation de débutants perpétuels, j e n'ai
pas de recommendantion particulière.

-- Gaby

On 11 sep, 15:52, "bpascal...@googlemail.com"
<bpascal...@googlemail.com> wrote:

> >>    Que fait-on des autres ?

ILS NE PERDENT PAS DE TEMPS AVEC DES TRUCS INUTILES : below :

...en bref, de l'utilité d'apprendre les pointeurs ?

Pour les pointeurs, avec mon niveau, je ne comprends pas toujours leur
utilité pour des programmes où les valeurs sont affectées directeme nt
aux variables.

http://www.bien-programmer.fr/notes.htm#pointeurs
http://www.bien-programmer.fr/notes.htm#util_pointeurs

On 11 sep, 20:07, candide <cand...@free.invalid> wrote:

Tu peux coder énormément de choses sans pointeur dès
lors que tu admet qu'une fonction peut changer les valeurs d'un tableau q uand
elle reçoit ce tableau en argument

Pas du C.

On 11 sep, 21:05, "bpascal...@googlemail.com"
<bpascal...@googlemail.com> wrote:

Au sujet de livre, j'attends le K&R.
En tant que comptable et non programmeur, est-ce que je peux attendre

A partir du moment où tu te mets à l'informatique et à la
programmation, tu deviens programmeur. Il est très courant que des
personnes ayant un métier donné, apprenne à utiliser l'outil
formidable qu'est la programmation, pour les aider dans ce métier. Par
contre, il faut s'y mettre vraiment et ne y aller "en se bouchant le
nez", comme tu en donnes souvent l'impression.

de la lecture de ce livre de progresser  en C ou bien ça ne sera
qu'une illusion? Je suppose que les auteurs ne l'ont pas écrit pour
des comptables, c'est pourquoi je demande.

Effectivement, ce livre n'est pas fait pour les débutants en
programmation, mais pour les programmeurs voulant apprendre le C.

Je ne suis pas sûr que le choix de passer directement de 'comptable' à
'programmeur C' soit une bonne idée... Apprendre le C depuis zéro
implique énormément de choses nouvelles, pour un résultat parfois
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.

Mon budget étant limité,

Il aurait donc été préférable de poser la question du livre avant d e
le commander ...

Au sujet des pointeurs, je comprends que c'est important. Comme ça a
été dit par Marc plus haut, je n'ai pas encore abordé le chapitre d e
la gestion mémoire et il semble que avant de jouer un autre rôle
surtout pour ce qui est de la manipulation des valeurs d'un tableau
simple (sans parler de la gestion de la mémoire), les pointeurs sont
là ne sont pas indispensables.

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.).

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[])

Dans les 2 cas, la valeur passée en argument est l'adresse d'un objet
de type T. Or, la seule façon de contenir une adresse est d'utiliser
une variable de type pointeur sur le type T. Dans les deux cas, a est
donc bien un pointeur sur un type T. Personnellement, j'utilise la
syntaxe T *a quand il s'agit de l'adresse d'une variable unique (pas
un tableau), et T a[] quand c'est l'adresse d'un élément de tableau.
Mais c'est juste pour auto-documenter le code. (et je ne l'ai pas
toujours fait dans le passé)

On 12 sep, 09:40, -ed- <emmanuel.delah...@gmail.com> wrote:

On 11 sep, 21:05, "bpascal...@googlemail.com"

<bpascal...@googlemail.com> wrote:
> Au sujet de livre, j'attends le K&R.
> En tant que comptable et non programmeur, est-ce que je peux attendre

A partir du moment où tu te mets à l'informatique et à la
programmation, tu deviens programmeur. Il est très courant que des
personnes ayant un métier donné, apprenne à utiliser l'outil
formidable qu'est la programmation, pour les aider dans ce métier. Par
contre, il faut s'y mettre vraiment et ne y aller "en se bouchant le
nez", comme tu en donnes souvent l'impression.

> de la lecture de ce livre de progresser  en C ou bien ça ne sera
> qu'une illusion? Je suppose que les auteurs ne l'ont pas écrit pour
> des comptables, c'est pourquoi je demande.

Effectivement, ce livre n'est pas fait pour les débutants en
programmation, mais pour les programmeurs voulant apprendre le C.

Je ne suis pas sûr que le choix de passer directement de 'comptable' à
'programmeur C' soit une bonne idée... Apprendre le C depuis zéro
implique énormément de choses nouvelles, pour un résultat parfois
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.

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 peut
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.

> Mon budget étant limité,

Il aurait donc été préférable de poser la question du livre avant de
le commander ...

> Au sujet des pointeurs, je comprends que c'est important. Comme ça a
> été dit par Marc plus haut, je n'ai pas encore abordé le chapitre de
> la gestion mémoire et il semble que avant de jouer un autre rôle
> surtout pour ce qui est de la manipulation des valeurs d'un tableau
> simple (sans parler de la gestion de la mémoire), les pointeurs sont
> là ne sont pas indispensables.

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.).

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[])

Dans les 2 cas, la valeur passée en argument est l'adresse d'un objet
de type T. Or, la seule façon de contenir une adresse est d'utiliser
une variable de type pointeur sur le type T. Dans les deux cas, a est
donc bien un pointeur sur un type T. Personnellement, j'utilise la
syntaxe T *a quand il s'agit de l'adresse d'une variable unique (pas
un tableau), et T a[] quand c'est l'adresse d'un élément de tableau.
Mais c'est juste pour auto-documenter le code. (et je ne l'ai pas
toujours fait dans le passé)

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".

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) ;


PERMUTER(X, Y);

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


return 0 ;

}


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


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

Nous appelons la fonction par:

PERMUTER(&X, &Y);


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



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 n e
connais pas ce langage alors je ne suis pas sûre des termes). Alors
que le C se compile du haut vers le bas.

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.

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] ;

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

>
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) ;

PERMUTER(X, Y);

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

return 0 ;

}

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

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

}

Nous appelons la fonction par:

   PERMUTER(&X, &Y);

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

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