... et ils ont viré le C

Michel Billaud

03/10/2004 à 14:58

Eric Deveaud writes:

Marc Boyer wrote:

Pourquoi ne pas commencer alors à Turing, puis le lamda-calcul
typé (équivalence de Church au passage si on a 2mn), puis le
reste n'est que mise en pratique ?

c'est bien le lambda calcul. C'est d'ailleur par schemeque j'ai appris la
programation, et aujourd'hui j'en rend grace à ceux qui ont fait ce
choix pédagogique
AMHA il faut en avoir fait un peu et touché d'autre "modes de
programations" pour ne pas se limiter conceptuelement.

Tout à fait.

À mon avis la première étape pour apprendre à programmer, c'est de se
familiariser avec la démarche consistant à décomposer un problème en
sous-problèmes, en spécifiant bien ce que font les morceaux, en
sachant qu'au bout de la chaine il y a tas de ferraille stupide qui ne
fait jamais que ce qu'on lui dit, et que ça se fait avec un langage
de programmation.

A ce niveau là, finalement, on s'en fout un peu de savoir si le
premier langage de programmation est répandu ou pas, ou même si c'est
du fonctionnel, de l'objet ou de l'impératif.

Une fois que les étudiants ont un peu avancé dans les "techniques de
résolution de problème", qu'ils savent spécifier et décomposer un
problème, tester les bouts etc, c'est là qu'on peut se préoccuper
d'avoir un "vrai" langage de programmation, ou mieux plusieurs.

Quel est le critère de "bonne méthode pédagogique" ? Pour moi,
c'est celle qui permet de faire entre de manière durable un max
d'information en un min de temps à un max d'élèves.

j'espère

tout à fait. Et ça ne se fait pas en leur apprenant un langage de
programmation unique sous prétexte que c'est "le plus important".

MB

--
Michel BILLAUD
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)

Michel Billaud

03/10/2004 à 15:04

Marc Boyer writes:

Stephane Zuckerman wrote:
On Wed, 29 Sep 2004, Johann Dantant wrote:
En fin de compte, ce qui a été déterminant, c'était la pédagogie.
Les enseignants étaient excellents, et ont artificiellement caché les
difficultés du C au départ pour nous permettre de nous concentrer sur
l'algorithmique .

J'ai pensé un temps faire un sous-ensemble de C avec un include
qui va bien pour utiliser C dès le début... J'ai trouvé le ratio
investissement/gain pas du tout interressant.
Tiens, comment lire un entier et une chaine de caractère
de manière homogène ?

macros LIRE_ENTIER et LIRE_CHAINE

Un problème avec ce genre d'approche : les étudiants se précipitent
pour lire les pires livres sur le langage dont on leur parle, et font une
tambouille infâme avec l'abstraction de haut niveau qu'on leur fournit
et les exemples des bouquins.

MB

--
Michel BILLAUD
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)

Michel Billaud

03/10/2004 à 17:46

Marc Boyer writes:

Par exemple, il faut pas coder longtemps pour réaliser
que les exceptions sont la meilleure solution à ce jour à la
gestion d'erreur.

En fait, les exceptions, c'est des goto dont ne sait même pas où ils
vont :)

MB
--
Michel BILLAUD
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)

Gabriel Dos Reis

03/10/2004 à 17:54

Michel Billaud writes:

| Marc Boyer writes:
|
| > Par exemple, il faut pas coder longtemps pour réaliser
| > que les exceptions sont la meilleure solution à ce jour à la
| > gestion d'erreur.
|
| En fait, les exceptions, c'est des goto dont ne sait même pas où ils
| vont :)

tout comme une fonction qui « retourne » ;-p

-- Gaby

Emmanuel Delahaye

03/10/2004 à 19:04

Rakotomandimby Mihamina wrote on 28/09/04 :

On Tue, 28 Sep 2004 10:56:45 +0200, Trognon Patrice wrote:

le K&R tu vas le trouver sur le net sans soucis.

Tu peux m'aider un peu ?

J'ai cherché avec les mots 'K&R en ligne' , 'telecharger K&R', ' Livre
K&R C ANSI' ... Bref un bon lot de combinaison de mots mais j'ai pas du
trouver celle qu'il faut pour degotter ce fameux livre...

Le vrai nom est "Le Langage C" par "Kernighan" et "Ritchie"

http://www.eyrolles.com/Informatique/Livre/9782100051168/

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Emmanuel Delahaye

03/10/2004 à 19:05

Yves Kuhry wrote on 28/09/04 :

On Tue, 28 Sep 2004 19:12:36 +0200
Rakotomandimby Mihamina wrote:

filetype:pdf "c programming language" kernighan

Illegal.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Emmanuel Delahaye

03/10/2004 à 19:08

Gaël Le Mignot wrote on 30/09/04 :

Par contre, la norme du C dit que "char" doit faire au moins
8-bits. Donc, sur les machines où le "byte" fait 4 bits, le "char"
faiut plusiuers "byte"...

Pour qu'une implémentation du C soit conforme, il faut que la plus
petite unité mémoire adressable fasse au moins 8 bits. Les processeurs
4-bits sont donc exclus d'une implémentation conforme. Ca n'empêche pas
de faire du C non standard, mais il vaut mieux le savoir.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Emmanuel Delahaye

03/10/2004 à 19:26

Charlie Gordon wrote on 30/09/04 :

Le mot byte est une altération de "bite" qui signifie bout, morceau,
bouchée, morsure, du verbe homographe "to bite" : mordre.
On a changé l'orthographe pour éviter la confusion avec bit.
L'usage en informatique pour désigner une quantité élémentaire de données
remonte à 1956 (Werner Buchholz, IBM), et représentait à l'origine un mot de
6 bits. Avant la fin de 1956, cette quantité était passée à 8 bits.

Et sur un DSP Texas TMS320C54, elle est de 16 bits...

Le fait est qu'un byte de 8 bits est appelé octet en anglais aussi, en
particulier dans le jargon formel des organismes de normalisation.

Non. Un octet se dit 'octet' en anglais. Dans le jargon 'telecom' (RFC
etc.), on fait la confusion byte / octet, mais pas dans le jargon
informatique et certainement pas dans la norme qui définit le langage C
(objet de ce forum, rappelons le).

Il existe effectivement des architectures informatiques où le mot
élémentaire a une taille étrange, voire délirante.

Jugement de valeur sans intérêt. Un DSP manipule plus souvent des
nombres que des chaines de caractères. Il est donc logique ques ses
'bytes' fassent 16, voire 32 bits.

Par exemple, de nombreux processeurs RISC sont incapables d'adresser la
mémoire par octet.

Bof, lesquels ? Tu ne confond pas avec les ralentissement (ou
impossibilités) pour adresser un mot de 16 ou 32 bits à une adresse
impaire ?

Or même sur ces architectures, le type C "char" est un
octet,

Non. SUr un DSP TI, CHAR_BIT vaut 16:

Trouvé 'CHAR_BIT' dans 'C:tic5400cgtoolsincludelimits.h' :
C:tic5400cgtoolsincludelimits.h(8): #define CHAR_BIT
16 /* NUMBER OF BITS IN TYPE CHAR */
Trouvé 'CHAR_BIT' 1 fois.

et le compilateur génère du code pour en adresser plusieurs par mot.

Tu racontes n'importe quoi...

Porter des programmes C sur des architectures où les bytes ne font pas 8
bits pose des problèmes bien souvent très difficiles à résoudre, en
particulier dès que des manipulations de bits sont faites.

Ajouter '& 0xFF'. Vachement dur!

Prétendre que le code C est portable dès lors qu'il respecte le standard C99
est une escroquerie.

Non, c'est une presomption. Ce n'est pas une garantie.

L'objectif du C99 et des précédents dans ce domaine est de définir ce qu'une
implémentation conforme peut faire sur différentes architectures en gardant
au language sa proximité avec le matériel et son efficacité.

Le K&R s'adresse aux débutants, il les met en garde contre la variabilité de
l'implémentation des types de base, mais gardons en perspective que par les
temps qui courent, les débutants n'ont pratiquement aucune chance de le
faire sur une machine où le byte n'est pas un octet, donc évitons de
rajouter de la complexité inutilement. Le C est déjà bien assez subtil et
piégeux comme cela.
Exemple:

int fillbuffer(int fd, char buffer[4096])
{
return read(fd, buffer, sizeof(buffer));
}

pourquoi cette routine ne fait-elle pas son office ?

Parce que la norme dit clairement que dans le cadre d'un paramètre de
fonction, les écritures

char *buffer
char buffer[]
char buffer[4096]

sont équivallentes.

Si tu veux un pointeur sur un tableau de 4096 bytes, il faut utiliser:

int fillbuffer(int fd, char (*buffer)[4096])
{
}

Dans ce cas, le sizeof fonctionne correctement.

Nota : cette méthode n'est cepedant pas recommandée si on cherche la
souplesse. Un paramètre de taille est préférable.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Charlie Gordon wrote on 30/09/04 :

Le mot byte est une altération de "bite" qui signifie bout, morceau,
bouchée, morsure, du verbe homographe "to bite" : mordre.
On a changé l'orthographe pour éviter la confusion avec bit.
L'usage en informatique pour désigner une quantité élémentaire de données
remonte à 1956 (Werner Buchholz, IBM), et représentait à l'origine un mot de
6 bits. Avant la fin de 1956, cette quantité était passée à 8 bits.

Et sur un DSP Texas TMS320C54, elle est de 16 bits...

Le fait est qu'un byte de 8 bits est appelé octet en anglais aussi, en
particulier dans le jargon formel des organismes de normalisation.

Non. Un octet se dit 'octet' en anglais. Dans le jargon 'telecom' (RFC
etc.), on fait la confusion byte / octet, mais pas dans le jargon
informatique et certainement pas dans la norme qui définit le langage C
(objet de ce forum, rappelons le).

Il existe effectivement des architectures informatiques où le mot
élémentaire a une taille étrange, voire délirante.

Jugement de valeur sans intérêt. Un DSP manipule plus souvent des
nombres que des chaines de caractères. Il est donc logique ques ses
'bytes' fassent 16, voire 32 bits.

Par exemple, de nombreux processeurs RISC sont incapables d'adresser la
mémoire par octet.

Bof, lesquels ? Tu ne confond pas avec les ralentissement (ou
impossibilités) pour adresser un mot de 16 ou 32 bits à une adresse
impaire ?

Or même sur ces architectures, le type C "char" est un
octet,

Non. SUr un DSP TI, CHAR_BIT vaut 16:

Trouvé 'CHAR_BIT' dans 'C:tic5400cgtoolsincludelimits.h' :
C:tic5400cgtoolsincludelimits.h(8): #define CHAR_BIT
16 /* NUMBER OF BITS IN TYPE CHAR */
Trouvé 'CHAR_BIT' 1 fois.

et le compilateur génère du code pour en adresser plusieurs par mot.

Tu racontes n'importe quoi...

Porter des programmes C sur des architectures où les bytes ne font pas 8
bits pose des problèmes bien souvent très difficiles à résoudre, en
particulier dès que des manipulations de bits sont faites.

Ajouter '& 0xFF'. Vachement dur!

Prétendre que le code C est portable dès lors qu'il respecte le standard C99
est une escroquerie.

Non, c'est une presomption. Ce n'est pas une garantie.

L'objectif du C99 et des précédents dans ce domaine est de définir ce qu'une
implémentation conforme peut faire sur différentes architectures en gardant
au language sa proximité avec le matériel et son efficacité.

Le K&R s'adresse aux débutants, il les met en garde contre la variabilité de
l'implémentation des types de base, mais gardons en perspective que par les
temps qui courent, les débutants n'ont pratiquement aucune chance de le
faire sur une machine où le byte n'est pas un octet, donc évitons de
rajouter de la complexité inutilement. Le C est déjà bien assez subtil et
piégeux comme cela.
Exemple:

int fillbuffer(int fd, char buffer[4096])
{
return read(fd, buffer, sizeof(buffer));
}

pourquoi cette routine ne fait-elle pas son office ?

Parce que la norme dit clairement que dans le cadre d'un paramètre de
fonction, les écritures

char *buffer
char buffer[]
char buffer[4096]

sont équivallentes.

Si tu veux un pointeur sur un tableau de 4096 bytes, il faut utiliser:

int fillbuffer(int fd, char (*buffer)[4096])
{
}

Dans ce cas, le sizeof fonctionne correctement.

Nota : cette méthode n'est cepedant pas recommandée si on cherche la
souplesse. Un paramètre de taille est préférable.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Vous avez filtré cet utilisateur ! Consultez son message

Charlie Gordon wrote on 30/09/04 :

Le mot byte est une altération de "bite" qui signifie bout, morceau,
bouchée, morsure, du verbe homographe "to bite" : mordre.
On a changé l'orthographe pour éviter la confusion avec bit.
L'usage en informatique pour désigner une quantité élémentaire de données
remonte à 1956 (Werner Buchholz, IBM), et représentait à l'origine un mot de
6 bits. Avant la fin de 1956, cette quantité était passée à 8 bits.

Et sur un DSP Texas TMS320C54, elle est de 16 bits...

Le fait est qu'un byte de 8 bits est appelé octet en anglais aussi, en
particulier dans le jargon formel des organismes de normalisation.

Non. Un octet se dit 'octet' en anglais. Dans le jargon 'telecom' (RFC
etc.), on fait la confusion byte / octet, mais pas dans le jargon
informatique et certainement pas dans la norme qui définit le langage C
(objet de ce forum, rappelons le).

Il existe effectivement des architectures informatiques où le mot
élémentaire a une taille étrange, voire délirante.

Jugement de valeur sans intérêt. Un DSP manipule plus souvent des
nombres que des chaines de caractères. Il est donc logique ques ses
'bytes' fassent 16, voire 32 bits.

Par exemple, de nombreux processeurs RISC sont incapables d'adresser la
mémoire par octet.

Bof, lesquels ? Tu ne confond pas avec les ralentissement (ou
impossibilités) pour adresser un mot de 16 ou 32 bits à une adresse
impaire ?

Or même sur ces architectures, le type C "char" est un
octet,

Non. SUr un DSP TI, CHAR_BIT vaut 16:

Trouvé 'CHAR_BIT' dans 'C:tic5400cgtoolsincludelimits.h' :
C:tic5400cgtoolsincludelimits.h(8): #define CHAR_BIT
16 /* NUMBER OF BITS IN TYPE CHAR */
Trouvé 'CHAR_BIT' 1 fois.

et le compilateur génère du code pour en adresser plusieurs par mot.

Tu racontes n'importe quoi...

Porter des programmes C sur des architectures où les bytes ne font pas 8
bits pose des problèmes bien souvent très difficiles à résoudre, en
particulier dès que des manipulations de bits sont faites.

Ajouter '& 0xFF'. Vachement dur!

Prétendre que le code C est portable dès lors qu'il respecte le standard C99
est une escroquerie.

Non, c'est une presomption. Ce n'est pas une garantie.

L'objectif du C99 et des précédents dans ce domaine est de définir ce qu'une
implémentation conforme peut faire sur différentes architectures en gardant
au language sa proximité avec le matériel et son efficacité.

Le K&R s'adresse aux débutants, il les met en garde contre la variabilité de
l'implémentation des types de base, mais gardons en perspective que par les
temps qui courent, les débutants n'ont pratiquement aucune chance de le
faire sur une machine où le byte n'est pas un octet, donc évitons de
rajouter de la complexité inutilement. Le C est déjà bien assez subtil et
piégeux comme cela.
Exemple:

int fillbuffer(int fd, char buffer[4096])
{
return read(fd, buffer, sizeof(buffer));
}

pourquoi cette routine ne fait-elle pas son office ?

Parce que la norme dit clairement que dans le cadre d'un paramètre de
fonction, les écritures

char *buffer
char buffer[]
char buffer[4096]

sont équivallentes.

Si tu veux un pointeur sur un tableau de 4096 bytes, il faut utiliser:

int fillbuffer(int fd, char (*buffer)[4096])
{
}

Dans ce cas, le sizeof fonctionne correctement.

Nota : cette méthode n'est cepedant pas recommandée si on cherche la
souplesse. Un paramètre de taille est préférable.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Emmanuel Delahaye

03/10/2004 à 19:28

Rakotomandimby Mihamina wrote on 29/09/04 :

J'ai tres bien compris. J'ai 0 argent de poche, et meme si ce livre

Tu fumes ?

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

Stephane Zuckerman

04/10/2004 à 01:33

Bonsoir,

/* création d'un type pour une chaîne de 19 caractères */
typedef char CH20;

J'ai pensé un temps faire un sous-ensemble de C avec un include
qui va bien pour utiliser C dès le début... J'ai trouvé le ratio
investissement/gain pas du tout interressant.

Pourquoi aller aussi loin ? Finalement, ce qui a été déterminant dans ma
formation, c'était le fait que tous les profs étaient synchro : le prof
d'archi nous expliquait les bases de l'électronique numérique ; le prof de
système aussi, du point de vue du S.E., et le prof d'algo/C aussi. Mais
bon, je conçois très bien qu'à la fac ou même dans une école d'ingénieur
ce soit plus difficile à faire ...

Nos outils en C étaient franchement très limités. Mis à part l'histoire du

typedef char CHxx; /* xx-1 caractères pour la chaîne */

nous n'avions que les types de base. Par contre, on nous disait deux
choses :
1) "Matez la doc"
2) "scanf, printf, ça marche comme ça [suivent plusieurs exemples]. Mais
ça sait faire d'autres trucs. *Matez la doc !*"

Tiens, comment lire un entier et une chaine de caractère
de manière homogène ?

Comme on te l'a proposé plus haut ;)

Je tiens quand même à dire que mon premier langage a été le C, et que je
n'en suis pas mort. Par contre, effectivement, j'avais de très bonnes
bases sur ce qu'était un ordinateur, ce qui me rendait compréhensible les
explications données autour du langage C.

Stéphane.

--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)

... et ils ont viré le C

10 réponses

Veuillez sélectionner un problème