Pour moi, l'apprentissage se fait en deux phases :
- la première on apprend à programmer et à écrire du code propre
- la seconde on regarde son architecture, son comportement, on
s'intéresse aux autres archi etc. Mais avant de faire cela, il faut
apprendre à écrire du code assez propre.
De toute façon, ce que je cherche n'existant pas, c'est ainsi que je
vais faire. Mais je ne démords du fait qu'un savant mélange des deux
domaines, tout en délimitant *précisément* à chaque fois dans lequel des
deux le discours s'applique, eu été pour moi une bénédiction. ;-)
Ah ... de toute façon ce livre ne semble pas exister. S'il en existe un
à votre connaissance, n'hésitez surtout pas (même si je sais que ce sera
à contre coeur :-)) )
Pour moi, l'apprentissage se fait en deux phases :
- la première on apprend à programmer et à écrire du code propre
- la seconde on regarde son architecture, son comportement, on
s'intéresse aux autres archi etc. Mais avant de faire cela, il faut
apprendre à écrire du code assez propre.
De toute façon, ce que je cherche n'existant pas, c'est ainsi que je
vais faire. Mais je ne démords du fait qu'un savant mélange des deux
domaines, tout en délimitant *précisément* à chaque fois dans lequel des
deux le discours s'applique, eu été pour moi une bénédiction. ;-)
Ah ... de toute façon ce livre ne semble pas exister. S'il en existe un
à votre connaissance, n'hésitez surtout pas (même si je sais que ce sera
à contre coeur :-)) )
Pour moi, l'apprentissage se fait en deux phases :
- la première on apprend à programmer et à écrire du code propre
- la seconde on regarde son architecture, son comportement, on
s'intéresse aux autres archi etc. Mais avant de faire cela, il faut
apprendre à écrire du code assez propre.
De toute façon, ce que je cherche n'existant pas, c'est ainsi que je
vais faire. Mais je ne démords du fait qu'un savant mélange des deux
domaines, tout en délimitant *précisément* à chaque fois dans lequel des
deux le discours s'applique, eu été pour moi une bénédiction. ;-)
Ah ... de toute façon ce livre ne semble pas exister. S'il en existe un
à votre connaissance, n'hésitez surtout pas (même si je sais que ce sera
à contre coeur :-)) )
On 8 mar, 15:06, Francois wrote:
Qu'on me dise que "le complément à 2 fait que l'addition devient
plus simple pour l'ordinateur puisqu'il suffit de faire une addition
classique" me suffit amplement.
Aucun rapport avec le C, le complément à deux concerne le processeur
ou ce qui l'émule, il te faut acheter un ouvrage sur un assembleur
quelconque ou un ouvrage d'architecture des ordinateurs.
On 8 mar, 15:06, Francois <mathsatta...@free.fr> wrote:
Qu'on me dise que "le complément à 2 fait que l'addition devient
plus simple pour l'ordinateur puisqu'il suffit de faire une addition
classique" me suffit amplement.
Aucun rapport avec le C, le complément à deux concerne le processeur
ou ce qui l'émule, il te faut acheter un ouvrage sur un assembleur
quelconque ou un ouvrage d'architecture des ordinateurs.
On 8 mar, 15:06, Francois wrote:
Qu'on me dise que "le complément à 2 fait que l'addition devient
plus simple pour l'ordinateur puisqu'il suffit de faire une addition
classique" me suffit amplement.
Aucun rapport avec le C, le complément à deux concerne le processeur
ou ce qui l'émule, il te faut acheter un ouvrage sur un assembleur
quelconque ou un ouvrage d'architecture des ordinateurs.
Ceci dit, je suis convaincu que pour bien programmer portable,
il est utile de connaître les origines des défauts de portabilité.
Je pense que comprendre qu'au niveau machine, c'est une opération qui
est signée ou non, alors qu'en C c'est la donnée qui est signée ou non
est très important, et qu'il est très intéressant de bien piger comment
on passe de l'un à l'autre.
Je ne connais pas de bouquin qui réponde à la demande de François. Je
dois dire que l'idée m'a effleuré d'en commettre un, à la suite d'un
autre.
L'approche aurait été de ne pas cacher la machine-modèle, mais au
contraire de montrer les pièges de toute présupposition sur sa nature.
Pour François, il me semble qu'il y a matière à expérimenter
efficacement, s'il a un peu de temps à perdre. Afficher par exemple ce
que les données ont dans le ventre.
Ceci dit, je suis convaincu que pour bien programmer portable,
il est utile de connaître les origines des défauts de portabilité.
Je pense que comprendre qu'au niveau machine, c'est une opération qui
est signée ou non, alors qu'en C c'est la donnée qui est signée ou non
est très important, et qu'il est très intéressant de bien piger comment
on passe de l'un à l'autre.
Je ne connais pas de bouquin qui réponde à la demande de François. Je
dois dire que l'idée m'a effleuré d'en commettre un, à la suite d'un
autre.
L'approche aurait été de ne pas cacher la machine-modèle, mais au
contraire de montrer les pièges de toute présupposition sur sa nature.
Pour François, il me semble qu'il y a matière à expérimenter
efficacement, s'il a un peu de temps à perdre. Afficher par exemple ce
que les données ont dans le ventre.
Ceci dit, je suis convaincu que pour bien programmer portable,
il est utile de connaître les origines des défauts de portabilité.
Je pense que comprendre qu'au niveau machine, c'est une opération qui
est signée ou non, alors qu'en C c'est la donnée qui est signée ou non
est très important, et qu'il est très intéressant de bien piger comment
on passe de l'un à l'autre.
Je ne connais pas de bouquin qui réponde à la demande de François. Je
dois dire que l'idée m'a effleuré d'en commettre un, à la suite d'un
autre.
L'approche aurait été de ne pas cacher la machine-modèle, mais au
contraire de montrer les pièges de toute présupposition sur sa nature.
Pour François, il me semble qu'il y a matière à expérimenter
efficacement, s'il a un peu de temps à perdre. Afficher par exemple ce
que les données ont dans le ventre.
Je
dois dire que l'idée m'a effleuré d'en commettre un, à la suite d'un
autre.
Je
dois dire que l'idée m'a effleuré d'en commettre un, à la suite d'un
autre.
Je
dois dire que l'idée m'a effleuré d'en commettre un, à la suite d'un
autre.
Dans notre formation, on enseigne
1) l'algorithmique
2) l'archi des ordis (simple)
3) le C
Tu peux essayer le 'C unleashed', les chapitres 5 et 6.
Dans notre formation, on enseigne
1) l'algorithmique
2) l'archi des ordis (simple)
3) le C
Tu peux essayer le 'C unleashed', les chapitres 5 et 6.
Dans notre formation, on enseigne
1) l'algorithmique
2) l'archi des ordis (simple)
3) le C
Tu peux essayer le 'C unleashed', les chapitres 5 et 6.
On 8 mar, 15:06, Francois wrote:
[...]Qu'on me dise que "le complément à 2 fait que l'addition devient
plus simple pour l'ordinateur puisqu'il suffit de faire une addition
classique" me suffit amplement.
Aucun rapport avec le C, le complément à deux concerne le processeur
ou ce qui l'émule, il te faut acheter un ouvrage sur un assembleur
quelconque ou un ouvrage d'architecture des ordinateurs.
Pas tout à fait d'accord. La représentation des entiers signés en
complément à deux est fortement présente dans la norme C. Soit par des
silences assourdissants - les ub - soit dans par exemple <stdint.h>,
qui impose pratiquement un modèle naturel sous-jacent d'entiers
naturels donc sans padding et des signés en complément à deux. OK,
c'est C99, mais c'est une extension bien pratique de beaucoup
d'implémentations C89.
On 8 mar, 15:06, Francois <mathsatta...@free.fr> wrote:
[...]
Qu'on me dise que "le complément à 2 fait que l'addition devient
plus simple pour l'ordinateur puisqu'il suffit de faire une addition
classique" me suffit amplement.
Aucun rapport avec le C, le complément à deux concerne le processeur
ou ce qui l'émule, il te faut acheter un ouvrage sur un assembleur
quelconque ou un ouvrage d'architecture des ordinateurs.
Pas tout à fait d'accord. La représentation des entiers signés en
complément à deux est fortement présente dans la norme C. Soit par des
silences assourdissants - les ub - soit dans par exemple <stdint.h>,
qui impose pratiquement un modèle naturel sous-jacent d'entiers
naturels donc sans padding et des signés en complément à deux. OK,
c'est C99, mais c'est une extension bien pratique de beaucoup
d'implémentations C89.
On 8 mar, 15:06, Francois wrote:
[...]Qu'on me dise que "le complément à 2 fait que l'addition devient
plus simple pour l'ordinateur puisqu'il suffit de faire une addition
classique" me suffit amplement.
Aucun rapport avec le C, le complément à deux concerne le processeur
ou ce qui l'émule, il te faut acheter un ouvrage sur un assembleur
quelconque ou un ouvrage d'architecture des ordinateurs.
Pas tout à fait d'accord. La représentation des entiers signés en
complément à deux est fortement présente dans la norme C. Soit par des
silences assourdissants - les ub - soit dans par exemple <stdint.h>,
qui impose pratiquement un modèle naturel sous-jacent d'entiers
naturels donc sans padding et des signés en complément à deux. OK,
c'est C99, mais c'est une extension bien pratique de beaucoup
d'implémentations C89.
On 8 mar, 15:06, Francois wrote:
[...]Qu'on me dise que "le complément à 2 fait que l'addition devient
plus simple pour l'ordinateur puisqu'il suffit de faire une addition
classique" me suffit amplement.
Aucun rapport avec le C, le complément à deux concerne le processeur
ou ce qui l'émule, il te faut acheter un ouvrage sur un assembleur
quelconque ou un ouvrage d'architecture des ordinateurs.
Pas tout à fait d'accord. La représentation des entiers signés en
complément à deux est fortement présente dans la norme C. Soit par des
silences assourdissants - les ub - soit dans par exemple <stdint.h>, qui
impose pratiquement un modèle naturel sous-jacent d'entiers naturels donc
sans padding et des signés en complément à deux. OK, c'est C99, mais c'est
une extension bien pratique de beaucoup d'implémentations C89.
Je ne conteste pas le fait qu'il est important de savoir programmer
portable. Ceci dit, je suis convaincu que pour bien programmer portable,
il est utile de connaître les origines des défauts de portabilité.
Je pense que comprendre qu'au niveau machine, c'est une opération qui est
signée ou non, alors qu'en C c'est la donnée qui est signée ou non est
très important, et qu'il est très intéressant de bien piger comment on
passe de l'un à l'autre.
Il est impératif que ceux qui savent ne prennent pas ceux qui apprennent,
et éventuellement ceux qui enseignent ou écrivent, pour des neuneus.
Il ne faudrait pas tomber dans un certain travers courant en C++, à
savoir que les gurus affirment qu'un bon programmeur C++ ne doit pas
connaître le C préalablement,
alors que leur propre niveau en C est généralement excellent, puisqu'ils
ont commencé par ce langage.
Le C est le langage idéal, un niche, pour interfacer du spécifique et du
portable. Je ne vois pas l'intérêt de programmer en C si on n'a pas une
idée assez précise des architectures sous-jacentes, le pluriel est
important.
Je ne connais pas de bouquin qui réponde à la demande de François. Je
dois dire que l'idée m'a effleuré d'en commettre un, à la suite d'un
autre. L'approche aurait été de ne pas cacher la machine-modèle, mais au
contraire de montrer les pièges de toute présupposition sur sa nature.
Pour François, il me semble qu'il y a matière à expérimenter
efficacement, s'il a un peu de temps à perdre. Afficher par exemple ce
que les données ont dans le ventre. Le problème étant de trouver le moyen
d'expérimenter sur de l'étrange. Bon, il y a DOS, et Mac éventuellement.
On 8 mar, 15:06, Francois <mathsatta...@free.fr> wrote:
[...]
Qu'on me dise que "le complément à 2 fait que l'addition devient
plus simple pour l'ordinateur puisqu'il suffit de faire une addition
classique" me suffit amplement.
Aucun rapport avec le C, le complément à deux concerne le processeur
ou ce qui l'émule, il te faut acheter un ouvrage sur un assembleur
quelconque ou un ouvrage d'architecture des ordinateurs.
Pas tout à fait d'accord. La représentation des entiers signés en
complément à deux est fortement présente dans la norme C. Soit par des
silences assourdissants - les ub - soit dans par exemple <stdint.h>, qui
impose pratiquement un modèle naturel sous-jacent d'entiers naturels donc
sans padding et des signés en complément à deux. OK, c'est C99, mais c'est
une extension bien pratique de beaucoup d'implémentations C89.
Je ne conteste pas le fait qu'il est important de savoir programmer
portable. Ceci dit, je suis convaincu que pour bien programmer portable,
il est utile de connaître les origines des défauts de portabilité.
Je pense que comprendre qu'au niveau machine, c'est une opération qui est
signée ou non, alors qu'en C c'est la donnée qui est signée ou non est
très important, et qu'il est très intéressant de bien piger comment on
passe de l'un à l'autre.
Il est impératif que ceux qui savent ne prennent pas ceux qui apprennent,
et éventuellement ceux qui enseignent ou écrivent, pour des neuneus.
Il ne faudrait pas tomber dans un certain travers courant en C++, à
savoir que les gurus affirment qu'un bon programmeur C++ ne doit pas
connaître le C préalablement,
alors que leur propre niveau en C est généralement excellent, puisqu'ils
ont commencé par ce langage.
Le C est le langage idéal, un niche, pour interfacer du spécifique et du
portable. Je ne vois pas l'intérêt de programmer en C si on n'a pas une
idée assez précise des architectures sous-jacentes, le pluriel est
important.
Je ne connais pas de bouquin qui réponde à la demande de François. Je
dois dire que l'idée m'a effleuré d'en commettre un, à la suite d'un
autre. L'approche aurait été de ne pas cacher la machine-modèle, mais au
contraire de montrer les pièges de toute présupposition sur sa nature.
Pour François, il me semble qu'il y a matière à expérimenter
efficacement, s'il a un peu de temps à perdre. Afficher par exemple ce
que les données ont dans le ventre. Le problème étant de trouver le moyen
d'expérimenter sur de l'étrange. Bon, il y a DOS, et Mac éventuellement.
On 8 mar, 15:06, Francois wrote:
[...]Qu'on me dise que "le complément à 2 fait que l'addition devient
plus simple pour l'ordinateur puisqu'il suffit de faire une addition
classique" me suffit amplement.
Aucun rapport avec le C, le complément à deux concerne le processeur
ou ce qui l'émule, il te faut acheter un ouvrage sur un assembleur
quelconque ou un ouvrage d'architecture des ordinateurs.
Pas tout à fait d'accord. La représentation des entiers signés en
complément à deux est fortement présente dans la norme C. Soit par des
silences assourdissants - les ub - soit dans par exemple <stdint.h>, qui
impose pratiquement un modèle naturel sous-jacent d'entiers naturels donc
sans padding et des signés en complément à deux. OK, c'est C99, mais c'est
une extension bien pratique de beaucoup d'implémentations C89.
Je ne conteste pas le fait qu'il est important de savoir programmer
portable. Ceci dit, je suis convaincu que pour bien programmer portable,
il est utile de connaître les origines des défauts de portabilité.
Je pense que comprendre qu'au niveau machine, c'est une opération qui est
signée ou non, alors qu'en C c'est la donnée qui est signée ou non est
très important, et qu'il est très intéressant de bien piger comment on
passe de l'un à l'autre.
Il est impératif que ceux qui savent ne prennent pas ceux qui apprennent,
et éventuellement ceux qui enseignent ou écrivent, pour des neuneus.
Il ne faudrait pas tomber dans un certain travers courant en C++, à
savoir que les gurus affirment qu'un bon programmeur C++ ne doit pas
connaître le C préalablement,
alors que leur propre niveau en C est généralement excellent, puisqu'ils
ont commencé par ce langage.
Le C est le langage idéal, un niche, pour interfacer du spécifique et du
portable. Je ne vois pas l'intérêt de programmer en C si on n'a pas une
idée assez précise des architectures sous-jacentes, le pluriel est
important.
Je ne connais pas de bouquin qui réponde à la demande de François. Je
dois dire que l'idée m'a effleuré d'en commettre un, à la suite d'un
autre. L'approche aurait été de ne pas cacher la machine-modèle, mais au
contraire de montrer les pièges de toute présupposition sur sa nature.
Pour François, il me semble qu'il y a matière à expérimenter
efficacement, s'il a un peu de temps à perdre. Afficher par exemple ce
que les données ont dans le ventre. Le problème étant de trouver le moyen
d'expérimenter sur de l'étrange. Bon, il y a DOS, et Mac éventuellement.
Ceci dit, je suis convaincu que pour bien programmer portable, il est
utile de connaître les origines des défauts de portabilité.
J'y connais pas des masses, mais j'approuve. D'une manière générale, le
"non dit" dans le but d'être irréprochable dans son discours est, selon
moins, une erreur pédagogique. Je trouve plus pédagogique de dire et de
montrer.
Dans la discussion que j'ai mise en lien dans premier message de ce fil, un
certain -ed- me disait "non, ça, c'est pas toujours vrai. Dans ce cas là
...". Il pouvait dire ça car, lui, il a probablement du voir et constater
(parfois à ces dépens) plein de problèmes du genre. Tant qu'on a pas vu...
Autre exemple (désolé, j'en reviens au maths).
a) Définition avec non dit irréprochable
UNE primitive de f sur I est une fonction F dérivable sur I tq F'=f
b) Définition sans non dit, irréprochable aussi
UNE primitive de f sur I est une fonction F dérivable sur I tq F'=f
Attention, on dit UNE, car si on en trouve une, alors on en déduit plein
d'autres en additionnant une constante. exple ...
Tout ça pour dire juste ceci :
Le problème, c'est que, lorsqu'on évite le non-dit, c'est plus difficile
(plus fatiguant) d'être irréprochable.
Pour moi, la pédagogie que j'aime, c'est celle de l'explicite (pas de non
dit). Où le lecteur ne doit pas jouer aux devinettes. Le tuto dont nous
avons parlé avant essaye de faire cela. Bon d'accord, hélas, il y a des
erreurs. Avec K&R, quant à lui, j'ai un peu l'impression qu'il faut
parfois jouer aux devinettes (cf : quelques messages avant à propos des
tableau). C'est une référence. Ca doit bien quand tu connais déjà très
bien le C et que dans ta tête les choses sont déjà bien en place.
a) Pour nos histoire de formalisme (lvalue etc.). Finalement, n'est-ce
pas un peu vain. Cela apporte-t-il quelque chose au programmeur ?
J'ai vraiment l'impression que ce formalisme de toute façon n'est pas
clairement et officiellement défini (je me trompe peut-être ?)
et j'ai l'impression aussi qu'au final, ce qui compte, c'est d'avoir sa
propre terminologie (en évitant quand même de faire un truc marginal) et
qu'elle soit cohérente. Non ?
b) Pouvez-vous me dire où je peux me procurer les normes C ?
Ceci dit, je suis convaincu que pour bien programmer portable, il est
utile de connaître les origines des défauts de portabilité.
J'y connais pas des masses, mais j'approuve. D'une manière générale, le
"non dit" dans le but d'être irréprochable dans son discours est, selon
moins, une erreur pédagogique. Je trouve plus pédagogique de dire et de
montrer.
Dans la discussion que j'ai mise en lien dans premier message de ce fil, un
certain -ed- me disait "non, ça, c'est pas toujours vrai. Dans ce cas là
...". Il pouvait dire ça car, lui, il a probablement du voir et constater
(parfois à ces dépens) plein de problèmes du genre. Tant qu'on a pas vu...
Autre exemple (désolé, j'en reviens au maths).
a) Définition avec non dit irréprochable
UNE primitive de f sur I est une fonction F dérivable sur I tq F'=f
b) Définition sans non dit, irréprochable aussi
UNE primitive de f sur I est une fonction F dérivable sur I tq F'=f
Attention, on dit UNE, car si on en trouve une, alors on en déduit plein
d'autres en additionnant une constante. exple ...
Tout ça pour dire juste ceci :
Le problème, c'est que, lorsqu'on évite le non-dit, c'est plus difficile
(plus fatiguant) d'être irréprochable.
Pour moi, la pédagogie que j'aime, c'est celle de l'explicite (pas de non
dit). Où le lecteur ne doit pas jouer aux devinettes. Le tuto dont nous
avons parlé avant essaye de faire cela. Bon d'accord, hélas, il y a des
erreurs. Avec K&R, quant à lui, j'ai un peu l'impression qu'il faut
parfois jouer aux devinettes (cf : quelques messages avant à propos des
tableau). C'est une référence. Ca doit bien quand tu connais déjà très
bien le C et que dans ta tête les choses sont déjà bien en place.
a) Pour nos histoire de formalisme (lvalue etc.). Finalement, n'est-ce
pas un peu vain. Cela apporte-t-il quelque chose au programmeur ?
J'ai vraiment l'impression que ce formalisme de toute façon n'est pas
clairement et officiellement défini (je me trompe peut-être ?)
et j'ai l'impression aussi qu'au final, ce qui compte, c'est d'avoir sa
propre terminologie (en évitant quand même de faire un truc marginal) et
qu'elle soit cohérente. Non ?
b) Pouvez-vous me dire où je peux me procurer les normes C ?
Ceci dit, je suis convaincu que pour bien programmer portable, il est
utile de connaître les origines des défauts de portabilité.
J'y connais pas des masses, mais j'approuve. D'une manière générale, le
"non dit" dans le but d'être irréprochable dans son discours est, selon
moins, une erreur pédagogique. Je trouve plus pédagogique de dire et de
montrer.
Dans la discussion que j'ai mise en lien dans premier message de ce fil, un
certain -ed- me disait "non, ça, c'est pas toujours vrai. Dans ce cas là
...". Il pouvait dire ça car, lui, il a probablement du voir et constater
(parfois à ces dépens) plein de problèmes du genre. Tant qu'on a pas vu...
Autre exemple (désolé, j'en reviens au maths).
a) Définition avec non dit irréprochable
UNE primitive de f sur I est une fonction F dérivable sur I tq F'=f
b) Définition sans non dit, irréprochable aussi
UNE primitive de f sur I est une fonction F dérivable sur I tq F'=f
Attention, on dit UNE, car si on en trouve une, alors on en déduit plein
d'autres en additionnant une constante. exple ...
Tout ça pour dire juste ceci :
Le problème, c'est que, lorsqu'on évite le non-dit, c'est plus difficile
(plus fatiguant) d'être irréprochable.
Pour moi, la pédagogie que j'aime, c'est celle de l'explicite (pas de non
dit). Où le lecteur ne doit pas jouer aux devinettes. Le tuto dont nous
avons parlé avant essaye de faire cela. Bon d'accord, hélas, il y a des
erreurs. Avec K&R, quant à lui, j'ai un peu l'impression qu'il faut
parfois jouer aux devinettes (cf : quelques messages avant à propos des
tableau). C'est une référence. Ca doit bien quand tu connais déjà très
bien le C et que dans ta tête les choses sont déjà bien en place.
a) Pour nos histoire de formalisme (lvalue etc.). Finalement, n'est-ce
pas un peu vain. Cela apporte-t-il quelque chose au programmeur ?
J'ai vraiment l'impression que ce formalisme de toute façon n'est pas
clairement et officiellement défini (je me trompe peut-être ?)
et j'ai l'impression aussi qu'au final, ce qui compte, c'est d'avoir sa
propre terminologie (en évitant quand même de faire un truc marginal) et
qu'elle soit cohérente. Non ?
b) Pouvez-vous me dire où je peux me procurer les normes C ?
Dans notre formation, on enseigne
1) l'algorithmique
2) l'archi des ordis (simple)
3) le C
OK. Et fait-on la liaison entre tout ça (préoccupation de François) ?
Tu peux essayer le 'C unleashed', les chapitres 5 et 6.
Chapitre 5 : Playing with bits and Bytes 5 (Lawrence Kerby)
Chapitre 6 : Offline Data storage and retrieval (Steeve Summit)
Les deux chapitres sont du "plain C" alors que si j'ai bien compris, ce
dont parle François est placé à l'interface du C et de la machine.
Je n'ai pas lu le chapitre 6 mais c'est assez verbeux (comme beaucoup de
chapitres de ce livre) et je vois que ça parle de lecture/écriture dans
des fichiers, des formats texte vs binaire, lecture d'un fichier de
configuration genre fichier .ini.
Je crois que ce qui intéresse François est beaucoup plus bas niveau.
Par contre, j'avais lu le chapitre 5 qui est un chapitre de contenu
assez classique bien que je ne l'ai pas trouvé spécialement clair en
première lecture.
Je trouve qu'il ne parle pas assez de la
"représentation des valeurs en C", ensuite il parle des 3 différentes
représentations classiques des entiers signés mais je suis resté sur ma
faim (il en parle là mais il n'en parle plus après donc c'est un peu
académique) puis il parle des opérations sur les bits d'entiers non
signés, très classique.
Une autre référence que j'aurais pu suggérer à François est le
chapitre 6 du Harbison & Steele et intitulée "Conversions and
representations".
J'ai lu le livre il y a quelque mois et j'ai trouvé ce
chapitre un des plus difficiles à assimiler et à cerner alors que sa
compréhension est sans doute essentielle pour franchir un cap dans
l'approfondissement du C. Difficile à lire parce que le sujet est
certainement complexe mais aussi parce que le talent d'exposition des
auteurs est proprement piètre.. Bon le chapitre parle de bits vs bytes,
de l'endianness (en première lecture, l'exposé m'a semblé bien
abstrait), de l'alignement, de la taille des pointeurs, c'est assez
disparate. Il y a ensuite un paragraphe abominable intitulé "Effects of
the adressing models" auquel je n'ai rien compris (bien que je l'ai lu
et relu) alors que ça traite de notions vraiment intéressantes au bout
du compte (ils disent qu'il existe des architectures très "difficiles"
pour implémenter le langage C mais hélas, je n'ai pas vraiment compris
leurs explications, elles ne sont pas assez concrètes, rien de
TANGIBLE). Il y a enfin un § sur la représentation des types mais assez
superficiel. Bref, je suis resté sur ma faim ou je n'ai pas compris. La
suite du chapitre (les conversions) est très spécifique au C et j'ai
beaucoup souffert en le lisant.
Dans notre formation, on enseigne
1) l'algorithmique
2) l'archi des ordis (simple)
3) le C
OK. Et fait-on la liaison entre tout ça (préoccupation de François) ?
Tu peux essayer le 'C unleashed', les chapitres 5 et 6.
Chapitre 5 : Playing with bits and Bytes 5 (Lawrence Kerby)
Chapitre 6 : Offline Data storage and retrieval (Steeve Summit)
Les deux chapitres sont du "plain C" alors que si j'ai bien compris, ce
dont parle François est placé à l'interface du C et de la machine.
Je n'ai pas lu le chapitre 6 mais c'est assez verbeux (comme beaucoup de
chapitres de ce livre) et je vois que ça parle de lecture/écriture dans
des fichiers, des formats texte vs binaire, lecture d'un fichier de
configuration genre fichier .ini.
Je crois que ce qui intéresse François est beaucoup plus bas niveau.
Par contre, j'avais lu le chapitre 5 qui est un chapitre de contenu
assez classique bien que je ne l'ai pas trouvé spécialement clair en
première lecture.
Je trouve qu'il ne parle pas assez de la
"représentation des valeurs en C", ensuite il parle des 3 différentes
représentations classiques des entiers signés mais je suis resté sur ma
faim (il en parle là mais il n'en parle plus après donc c'est un peu
académique) puis il parle des opérations sur les bits d'entiers non
signés, très classique.
Une autre référence que j'aurais pu suggérer à François est le
chapitre 6 du Harbison & Steele et intitulée "Conversions and
representations".
J'ai lu le livre il y a quelque mois et j'ai trouvé ce
chapitre un des plus difficiles à assimiler et à cerner alors que sa
compréhension est sans doute essentielle pour franchir un cap dans
l'approfondissement du C. Difficile à lire parce que le sujet est
certainement complexe mais aussi parce que le talent d'exposition des
auteurs est proprement piètre.. Bon le chapitre parle de bits vs bytes,
de l'endianness (en première lecture, l'exposé m'a semblé bien
abstrait), de l'alignement, de la taille des pointeurs, c'est assez
disparate. Il y a ensuite un paragraphe abominable intitulé "Effects of
the adressing models" auquel je n'ai rien compris (bien que je l'ai lu
et relu) alors que ça traite de notions vraiment intéressantes au bout
du compte (ils disent qu'il existe des architectures très "difficiles"
pour implémenter le langage C mais hélas, je n'ai pas vraiment compris
leurs explications, elles ne sont pas assez concrètes, rien de
TANGIBLE). Il y a enfin un § sur la représentation des types mais assez
superficiel. Bref, je suis resté sur ma faim ou je n'ai pas compris. La
suite du chapitre (les conversions) est très spécifique au C et j'ai
beaucoup souffert en le lisant.
Dans notre formation, on enseigne
1) l'algorithmique
2) l'archi des ordis (simple)
3) le C
OK. Et fait-on la liaison entre tout ça (préoccupation de François) ?
Tu peux essayer le 'C unleashed', les chapitres 5 et 6.
Chapitre 5 : Playing with bits and Bytes 5 (Lawrence Kerby)
Chapitre 6 : Offline Data storage and retrieval (Steeve Summit)
Les deux chapitres sont du "plain C" alors que si j'ai bien compris, ce
dont parle François est placé à l'interface du C et de la machine.
Je n'ai pas lu le chapitre 6 mais c'est assez verbeux (comme beaucoup de
chapitres de ce livre) et je vois que ça parle de lecture/écriture dans
des fichiers, des formats texte vs binaire, lecture d'un fichier de
configuration genre fichier .ini.
Je crois que ce qui intéresse François est beaucoup plus bas niveau.
Par contre, j'avais lu le chapitre 5 qui est un chapitre de contenu
assez classique bien que je ne l'ai pas trouvé spécialement clair en
première lecture.
Je trouve qu'il ne parle pas assez de la
"représentation des valeurs en C", ensuite il parle des 3 différentes
représentations classiques des entiers signés mais je suis resté sur ma
faim (il en parle là mais il n'en parle plus après donc c'est un peu
académique) puis il parle des opérations sur les bits d'entiers non
signés, très classique.
Une autre référence que j'aurais pu suggérer à François est le
chapitre 6 du Harbison & Steele et intitulée "Conversions and
representations".
J'ai lu le livre il y a quelque mois et j'ai trouvé ce
chapitre un des plus difficiles à assimiler et à cerner alors que sa
compréhension est sans doute essentielle pour franchir un cap dans
l'approfondissement du C. Difficile à lire parce que le sujet est
certainement complexe mais aussi parce que le talent d'exposition des
auteurs est proprement piètre.. Bon le chapitre parle de bits vs bytes,
de l'endianness (en première lecture, l'exposé m'a semblé bien
abstrait), de l'alignement, de la taille des pointeurs, c'est assez
disparate. Il y a ensuite un paragraphe abominable intitulé "Effects of
the adressing models" auquel je n'ai rien compris (bien que je l'ai lu
et relu) alors que ça traite de notions vraiment intéressantes au bout
du compte (ils disent qu'il existe des architectures très "difficiles"
pour implémenter le langage C mais hélas, je n'ai pas vraiment compris
leurs explications, elles ne sont pas assez concrètes, rien de
TANGIBLE). Il y a enfin un § sur la représentation des types mais assez
superficiel. Bref, je suis resté sur ma faim ou je n'ai pas compris. La
suite du chapitre (les conversions) est très spécifique au C et j'ai
beaucoup souffert en le lisant.
Ce n'est qu'un problème. Un gros problème est qu'on finit par arriver à
des considérations de mécanique quantique... je veux dire des
considérations plus compliquées que ce qu'on cherche à expliquer. Un autre
gros problèmes et que toutes ces considérations annexes finissent par
consommer des ressources qui seraient au final mieux consommées à autre
chose. Ce n'est pas un livre que tu veux, c'est une bibliothèque... Et il
faut bien commencer par quelque chose.
et j'ai l'impression aussi qu'au final, ce qui compte, c'est d'avoir sa
propre terminologie (en évitant quand même de faire un truc marginal) et
qu'elle soit cohérente. Non ?
Se batir sa propre terminologie, c'est bien jusqu'au jour où on veut parler
avec quelqu'un.
b) Pouvez-vous me dire où je peux me procurer les normes C ?
[couic]
est probablement le document le plus à jour que tu puisses obtenir
-- gratuitement ou non d'ailleurs.
Ce n'est qu'un problème. Un gros problème est qu'on finit par arriver à
des considérations de mécanique quantique... je veux dire des
considérations plus compliquées que ce qu'on cherche à expliquer. Un autre
gros problèmes et que toutes ces considérations annexes finissent par
consommer des ressources qui seraient au final mieux consommées à autre
chose. Ce n'est pas un livre que tu veux, c'est une bibliothèque... Et il
faut bien commencer par quelque chose.
et j'ai l'impression aussi qu'au final, ce qui compte, c'est d'avoir sa
propre terminologie (en évitant quand même de faire un truc marginal) et
qu'elle soit cohérente. Non ?
Se batir sa propre terminologie, c'est bien jusqu'au jour où on veut parler
avec quelqu'un.
b) Pouvez-vous me dire où je peux me procurer les normes C ?
[couic]
est probablement le document le plus à jour que tu puisses obtenir
-- gratuitement ou non d'ailleurs.
Ce n'est qu'un problème. Un gros problème est qu'on finit par arriver à
des considérations de mécanique quantique... je veux dire des
considérations plus compliquées que ce qu'on cherche à expliquer. Un autre
gros problèmes et que toutes ces considérations annexes finissent par
consommer des ressources qui seraient au final mieux consommées à autre
chose. Ce n'est pas un livre que tu veux, c'est une bibliothèque... Et il
faut bien commencer par quelque chose.
et j'ai l'impression aussi qu'au final, ce qui compte, c'est d'avoir sa
propre terminologie (en évitant quand même de faire un truc marginal) et
qu'elle soit cohérente. Non ?
Se batir sa propre terminologie, c'est bien jusqu'au jour où on veut parler
avec quelqu'un.
b) Pouvez-vous me dire où je peux me procurer les normes C ?
[couic]
est probablement le document le plus à jour que tu puisses obtenir
-- gratuitement ou non d'ailleurs.