C'est incroyable, la Fac d'orleans vient de passer au LMD et ils ont viré
le C des programmes.
Ils ont conservé le Caml pour les 2eme années
Et ont remplacé Pascal (1ere année) et C (2eme année) par je Java sur
les deux années.
En troisieme on aura directement droit au C++.
Je trouve ca injuste. Et dire que j'etais vraiment content de faire du C,
d'autant plus que je tourne uniquement sous Linux et que sous Linux le C
est tres abondant ... je devrais donc apprendre le C a coté : une masse
de travail supplémentaire ... Quel desastre ... vous voyez un bon coté
des choses dans cette histoire, moi je suis un tantinet deprimé la ...
--
ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance
Unofficial FAQ fcolc - http://faq.fcolc.eu.org/
Linux User Group sur Orléans et alentours.
Tél: + 33 2 38 76 43 65 (France)
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
J'ai renoncé à l'approche par macros parce que les messages d'erreurs ne sont pas homogènes (puisqu'ils se rapportent au code expensé alors que l'étudiant ne voit que le code source).
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.
J'avais pas pensé à ça... Ca doit pas aider en effet.
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Michel Billaud wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
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
J'ai renoncé à l'approche par macros parce que les
messages d'erreurs ne sont pas homogènes (puisqu'ils
se rapportent au code expensé alors que l'étudiant
ne voit que le code source).
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.
J'avais pas pensé à ça... Ca doit pas aider en effet.
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
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
J'ai renoncé à l'approche par macros parce que les messages d'erreurs ne sont pas homogènes (puisqu'ils se rapportent au code expensé alors que l'étudiant ne voit que le code source).
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.
J'avais pas pensé à ça... Ca doit pas aider en effet.
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Marc Boyer
Stephane Zuckerman wrote:
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.
Oui, c'est pour cela que je disais "bonne chance". Déjà que faire un emplois du temps où chaque enseignant ne fait qu'un seul cours à la fois c'est pas gagné ;-)
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 !*"
Sauf que pour comprendre la doc de scanf et printf il faut avoir compris les pointeurs et le cas particulier des tableaux. Moi, j'aime bien pouvoir avoir quelques semaines avant de devoir introduire les pointeurs à des débutants.
Je tiens quand même à dire que mon premier langage a été le C, et que je n'en suis pas mort.
Certains élèves ont appris le latin à coups de baguette sur les doigts.
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.
Ce qui me dérange dans cette optique, c'est le problème de la poule et de l'oeuf: comment faire de l'assembleur sans avoir manipulé d'algorithmique ?
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Stephane Zuckerman wrote:
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.
Oui, c'est pour cela que je disais "bonne chance". Déjà que
faire un emplois du temps où chaque enseignant ne fait qu'un seul
cours à la fois c'est pas gagné ;-)
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 !*"
Sauf que pour comprendre la doc de scanf et printf il faut avoir
compris les pointeurs et le cas particulier des tableaux.
Moi, j'aime bien pouvoir avoir quelques semaines avant
de devoir introduire les pointeurs à des débutants.
Je tiens quand même à dire que mon premier langage a été le C, et que je
n'en suis pas mort.
Certains élèves ont appris le latin à coups de baguette sur
les doigts.
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.
Ce qui me dérange dans cette optique, c'est le problème de
la poule et de l'oeuf: comment faire de l'assembleur sans
avoir manipulé d'algorithmique ?
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
/* 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.
Oui, c'est pour cela que je disais "bonne chance". Déjà que faire un emplois du temps où chaque enseignant ne fait qu'un seul cours à la fois c'est pas gagné ;-)
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 !*"
Sauf que pour comprendre la doc de scanf et printf il faut avoir compris les pointeurs et le cas particulier des tableaux. Moi, j'aime bien pouvoir avoir quelques semaines avant de devoir introduire les pointeurs à des débutants.
Je tiens quand même à dire que mon premier langage a été le C, et que je n'en suis pas mort.
Certains élèves ont appris le latin à coups de baguette sur les doigts.
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.
Ce qui me dérange dans cette optique, c'est le problème de la poule et de l'oeuf: comment faire de l'assembleur sans avoir manipulé d'algorithmique ?
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Marc Boyer
Michel Billaud wrote:
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 :)
Exactement, puisque quand on l'écrit, on ne sait pas où on doit aller.
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Michel Billaud wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> 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 :)
Exactement, puisque quand on l'écrit, on ne sait pas
où on doit aller.
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
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 :)
Exactement, puisque quand on l'écrit, on ne sait pas où on doit aller.
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Stephane Zuckerman
On Mon, 4 Oct 2004, Marc Boyer wrote:
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.
Ce qui me dérange dans cette optique, c'est le problème de la poule et de l'oeuf: comment faire de l'assembleur sans avoir manipulé d'algorithmique ?
Au début nous faisions de l'algorithmique sans comprendre ce qu'était un pointeur du tout. On savait juste faire des gets() (même pas fgets()), des scanf(), et des printf(). A côté de ça, les structures de données les plus compliquées au début étaient les tableaux (et encore, pas tout à fait au début - comme un cours d'algo quoi :-) ).
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)
On Mon, 4 Oct 2004, Marc Boyer wrote:
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.
Ce qui me dérange dans cette optique, c'est le problème de
la poule et de l'oeuf: comment faire de l'assembleur sans
avoir manipulé d'algorithmique ?
Au début nous faisions de l'algorithmique sans comprendre ce qu'était un
pointeur du tout. On savait juste faire des gets() (même pas fgets()), des
scanf(), et des printf(). A côté de ça, les structures de données les plus
compliquées au début étaient les tableaux (et encore, pas tout à fait au
début - comme un cours d'algo quoi :-) ).
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)
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.
Ce qui me dérange dans cette optique, c'est le problème de la poule et de l'oeuf: comment faire de l'assembleur sans avoir manipulé d'algorithmique ?
Au début nous faisions de l'algorithmique sans comprendre ce qu'était un pointeur du tout. On savait juste faire des gets() (même pas fgets()), des scanf(), et des printf(). A côté de ça, les structures de données les plus compliquées au début étaient les tableaux (et encore, pas tout à fait au début - comme un cours d'algo quoi :-) ).
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)
Marc Boyer
Stephane Zuckerman wrote:
On Mon, 4 Oct 2004, Marc Boyer wrote:
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.
Ce qui me dérange dans cette optique, c'est le problème de la poule et de l'oeuf: comment faire de l'assembleur sans avoir manipulé d'algorithmique ?
Au début nous faisions de l'algorithmique sans comprendre ce qu'était un pointeur du tout. On savait juste faire des gets() (même pas fgets()), des scanf(), et des printf().
C'est à dire que vous écriviez scanf("%d",&i); mais sans vraiment savoir ce que ça faisait.
A côté de ça, les structures de données les plus compliquées au début étaient les tableaux (et encore, pas tout à fait au début - comme un cours d'algo quoi :-) ).
Mais passer un tableau à une fonction en C est inhomogène avec les autres passages de paramètre...
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Stephane Zuckerman wrote:
On Mon, 4 Oct 2004, Marc Boyer wrote:
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.
Ce qui me dérange dans cette optique, c'est le problème de
la poule et de l'oeuf: comment faire de l'assembleur sans
avoir manipulé d'algorithmique ?
Au début nous faisions de l'algorithmique sans comprendre ce qu'était un
pointeur du tout. On savait juste faire des gets() (même pas fgets()), des
scanf(), et des printf().
C'est à dire que vous écriviez
scanf("%d",&i);
mais sans vraiment savoir ce que ça faisait.
A côté de ça, les structures de données les plus
compliquées au début étaient les tableaux (et encore, pas tout à fait au
début - comme un cours d'algo quoi :-) ).
Mais passer un tableau à une fonction en C est inhomogène
avec les autres passages de paramètre...
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
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.
Ce qui me dérange dans cette optique, c'est le problème de la poule et de l'oeuf: comment faire de l'assembleur sans avoir manipulé d'algorithmique ?
Au début nous faisions de l'algorithmique sans comprendre ce qu'était un pointeur du tout. On savait juste faire des gets() (même pas fgets()), des scanf(), et des printf().
C'est à dire que vous écriviez scanf("%d",&i); mais sans vraiment savoir ce que ça faisait.
A côté de ça, les structures de données les plus compliquées au début étaient les tableaux (et encore, pas tout à fait au début - comme un cours d'algo quoi :-) ).
Mais passer un tableau à une fonction en C est inhomogène avec les autres passages de paramètre...
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Stephane Zuckerman
C'est à dire que vous écriviez scanf("%d",&i); mais sans vraiment savoir ce que ça faisait. Exactement.
Mais passer un tableau à une fonction en C est inhomogène avec les autres passages de paramètre...
-- "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)
C'est à dire que vous écriviez
scanf("%d",&i);
mais sans vraiment savoir ce que ça faisait.
Exactement.
Mais passer un tableau à une fonction en C est inhomogène
avec les autres passages de paramètre...
--
"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)
-- "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)
Marc Boyer
Stephane Zuckerman wrote:
Mais passer un tableau à une fonction en C est inhomogène avec les autres passages de paramètre...
Sauf que c'est un accès en lecture/écriture au tableau, alors que, en algorithmique au début, j'aime bien pouvoir distinguer in, out, in/out. Et puis on perd la taille du tableau...
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Stephane Zuckerman wrote:
Mais passer un tableau à une fonction en C est inhomogène
avec les autres passages de paramètre...
Sauf que c'est un accès en lecture/écriture au tableau, alors
que, en algorithmique au début, j'aime bien pouvoir distinguer
in, out, in/out.
Et puis on perd la taille du tableau...
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
Sauf que c'est un accès en lecture/écriture au tableau, alors que, en algorithmique au début, j'aime bien pouvoir distinguer in, out, in/out. Et puis on perd la taille du tableau...
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Stephane Zuckerman
On Mon, 4 Oct 2004, Marc Boyer wrote:
int f(char tableau[], int nb_chaines);
Sauf que c'est un accès en lecture/écriture au tableau, alors que, en algorithmique au début, j'aime bien pouvoir distinguer in, out, in/out.
Ca je veux bien comprendre qu'on puisse être gêné (même si je n'ai jamais réellement [comprendre : "formellement"] utilisé la distinction in/out en algo)?
Et puis on perd la taille du tableau...
Est-ce vraiment important ? Après tout, la taille est passée directement en paramètre, et le prof nous rappelait bien qu'il fallait le faire.
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)
On Mon, 4 Oct 2004, Marc Boyer wrote:
int f(char tableau[], int nb_chaines);
Sauf que c'est un accès en lecture/écriture au tableau, alors
que, en algorithmique au début, j'aime bien pouvoir distinguer
in, out, in/out.
Ca je veux bien comprendre qu'on puisse être gêné (même si je n'ai jamais
réellement [comprendre : "formellement"] utilisé la distinction in/out en
algo)?
Et puis on perd la taille du tableau...
Est-ce vraiment important ? Après tout, la taille est passée directement
en paramètre, et le prof nous rappelait bien qu'il fallait le faire.
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)
Sauf que c'est un accès en lecture/écriture au tableau, alors que, en algorithmique au début, j'aime bien pouvoir distinguer in, out, in/out.
Ca je veux bien comprendre qu'on puisse être gêné (même si je n'ai jamais réellement [comprendre : "formellement"] utilisé la distinction in/out en algo)?
Et puis on perd la taille du tableau...
Est-ce vraiment important ? Après tout, la taille est passée directement en paramètre, et le prof nous rappelait bien qu'il fallait le faire.
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)
Marc Boyer
Stephane Zuckerman wrote:
On Mon, 4 Oct 2004, Marc Boyer wrote:
int f(char tableau[], int nb_chaines);
Sauf que c'est un accès en lecture/écriture au tableau, alors que, en algorithmique au début, j'aime bien pouvoir distinguer in, out, in/out.
Ca je veux bien comprendre qu'on puisse être gêné (même si je n'ai jamais réellement [comprendre : "formellement"] utilisé la distinction in/out en algo)?
Ben pour des débutants, quand on écrit un flot de données, ça permet de leur faire se souvenir que si une variable est in, il faut qu'elle soit initialisée avant l'appel. Ce genre de chose...
Et puis on perd la taille du tableau...
Est-ce vraiment important ? Après tout, la taille est passée directement en paramètre, et le prof nous rappelait bien qu'il fallait le faire.
C'est ce que j'appelle "bonne chance". Les élèves doivent retenir pleins de choses alors qu'en commençant par un autre langage, on pourrait se concentrer sur autre chose.
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Stephane Zuckerman wrote:
On Mon, 4 Oct 2004, Marc Boyer wrote:
int f(char tableau[], int nb_chaines);
Sauf que c'est un accès en lecture/écriture au tableau, alors
que, en algorithmique au début, j'aime bien pouvoir distinguer
in, out, in/out.
Ca je veux bien comprendre qu'on puisse être gêné (même si je n'ai jamais
réellement [comprendre : "formellement"] utilisé la distinction in/out en
algo)?
Ben pour des débutants, quand on écrit un flot de données, ça
permet de leur faire se souvenir que si une variable est in,
il faut qu'elle soit initialisée avant l'appel. Ce genre de chose...
Et puis on perd la taille du tableau...
Est-ce vraiment important ? Après tout, la taille est passée directement
en paramètre, et le prof nous rappelait bien qu'il fallait le faire.
C'est ce que j'appelle "bonne chance". Les élèves doivent retenir
pleins de choses alors qu'en commençant par un autre langage, on
pourrait se concentrer sur autre chose.
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
Sauf que c'est un accès en lecture/écriture au tableau, alors que, en algorithmique au début, j'aime bien pouvoir distinguer in, out, in/out.
Ca je veux bien comprendre qu'on puisse être gêné (même si je n'ai jamais réellement [comprendre : "formellement"] utilisé la distinction in/out en algo)?
Ben pour des débutants, quand on écrit un flot de données, ça permet de leur faire se souvenir que si une variable est in, il faut qu'elle soit initialisée avant l'appel. Ce genre de chose...
Et puis on perd la taille du tableau...
Est-ce vraiment important ? Après tout, la taille est passée directement en paramètre, et le prof nous rappelait bien qu'il fallait le faire.
C'est ce que j'appelle "bonne chance". Les élèves doivent retenir pleins de choses alors qu'en commençant par un autre langage, on pourrait se concentrer sur autre chose.
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Vincent Lefevre
Dans l'article , Emmanuel Delahaye écrit:
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.
Non, il suffit que l'implémentation regroupe deux mots de 4 bits et applique un facteur 2 sur toutes les adresses réelles.
Dans l'article <mn.1c7c7d4af7caae88.15512@YOURBRAnoos.fr>,
Emmanuel Delahaye <emdel@yourbranoos.fr> écrit:
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.
Non, il suffit que l'implémentation regroupe deux mots de 4 bits
et applique un facteur 2 sur toutes les adresses réelles.
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.
Non, il suffit que l'implémentation regroupe deux mots de 4 bits et applique un facteur 2 sur toutes les adresses réelles.
