Bonjour =E0 toutes et =E0 tous,
quel livre me conseilleriez vous sur le langage C, plutot orient=E9 microco=
ntroleurs...
Je pr=E9cise que je suis technicien en =E9lectronique, et que j'ai quand me=
me des notions de programmations...
J'ai vu rapidement le langage en BTS, mais il m'a toujours rebut=E9, m=EAme=
si je reste persuad=E9 qu'il est puissant, versatile, portable, enfin bref=
bourr=E9 de qualit=E9s connues et reconnues...=20
Sinon, =E0 part =E7a, vous allez vous moquer de moi, mais j'ai commenc=E9 =
=E0 "bidouiller" en BASIC =E0 la fin des ann=E9es 80 sur le Commodore C64 d=
e mon fr=E8re... En plus le "Basic V2" du C64 n'=E9tait deja pas une r=E9f=
=E9rence !
Un peu plus tard, j'ai bidouill=E9 en Visual Basic 1.0, puis en Quick Basic=
4.5, ...
En BTS je me suis =E9clat=E9 en assembleur 68705 et 68HC11... Et pour la su=
ite, plus grand chose, =E0 mon grand regret !
J'ai d=E9ja post=E9 un message =E0 ce sujet sur fr.sci.electronique, beauco=
up m'ont conseill=E9 le K&R, ou le ANSI C.
Merci par avance de votre aide !
C'est drôle d'apprécier l'indentation au point d'indenter ses messages dans Usenet, et de la détester dans un langage qui l'impose... ;-)
Pas qui l'impose : qui lui donne une sémantique, et différente de l'effet visuel obtenu.
5 6
Pour moi 5 et 6 sont indentés différements, pour python ils sont indentés de même manière...
Je ne comprends pas. On peut indenter comme on veut, mais il faut une certaine cohérence quand même. Les deux indentations que tu montres ne peuvent pas être présente dans le même bloc ; 5 et 6 ne sont donc pas indentés de la même manière :
Oui moi aussi je n'ai pas compris. Il y a un truc qui m'échappe dans ce qu'a dit Erwan.
-- François Lafont
Le 29/08/2012 07:53, Richard Delorme a écrit :
Le 28/08/2012 20:24, Erwan David a écrit :
Richard Delorme <abulmo@nospam.fr> écrivait :
C'est drôle d'apprécier l'indentation au point d'indenter ses messages
dans Usenet, et de la détester dans un langage qui l'impose... ;-)
Pas qui l'impose : qui lui donne une sémantique, et différente de
l'effet visuel obtenu.
5
6
Pour moi 5 et 6 sont indentés différements, pour python ils sont
indentés de même manière...
Je ne comprends pas. On peut indenter comme on veut, mais il faut une
certaine cohérence quand même. Les deux indentations que tu montres ne
peuvent pas être présente dans le même bloc ; 5 et 6 ne sont donc pas
indentés de la même manière :
C'est drôle d'apprécier l'indentation au point d'indenter ses messages dans Usenet, et de la détester dans un langage qui l'impose... ;-)
Pas qui l'impose : qui lui donne une sémantique, et différente de l'effet visuel obtenu.
5 6
Pour moi 5 et 6 sont indentés différements, pour python ils sont indentés de même manière...
Je ne comprends pas. On peut indenter comme on veut, mais il faut une certaine cohérence quand même. Les deux indentations que tu montres ne peuvent pas être présente dans le même bloc ; 5 et 6 ne sont donc pas indentés de la même manière :
Oui moi aussi je n'ai pas compris. Il y a un truc qui m'échappe dans ce qu'a dit Erwan.
Si je peux ajouter mon grain de sel. Je pense qu'il fait référence aux pbs de taille de tabulation. Ainsi sur certains outils ou terminaux le tab vaut 8 espaces, et pour d'autres 4. Au final les chaines (s=espace t=tab)
ssssssss5 et: t6
représentant la même indentation seront affichées par un terminal (ou par un outil d'édition) comme:
^ 5 ^ 6 ou: ^ 5 ^ 6
C'est à dire comme n'ayant pas "visuellement" la même indentation. Ca ne change pas la sémantique du code (les niveaux d'indentations sont identiques: 1 tabulation), mais peut induire une erreur de lecture chez l'humain.
Le problème est lié aux mélange des conventions s ou t et n'est pas propre à python puisque même en C on peut se retrouver avec une indentations visuellement foireuses dans ce cas. A ce moment là les '{' peuvent aider; mais je pense que lorsqu'un humain relis un code, il ne regarde pas les accolades au 1er coup et se fie aux indentations en priorité. Un code écrit sans indentation est considéré comme illisible:
Oui moi aussi je n'ai pas compris. Il y a un truc qui m'échappe dans ce
qu'a dit Erwan.
Si je peux ajouter mon grain de sel. Je pense qu'il fait référence aux
pbs de taille de tabulation. Ainsi sur certains outils ou terminaux le
tab vaut 8 espaces, et pour d'autres 4. Au final les chaines (s=espace
t=tab)
ssssssss5
et:
t6
représentant la même indentation seront affichées par un terminal (ou
par un outil d'édition) comme:
^ 5
^ 6
ou:
^ 5
^ 6
C'est à dire comme n'ayant pas "visuellement" la même indentation. Ca ne
change pas la sémantique du code (les niveaux d'indentations sont
identiques: 1 tabulation), mais peut induire une erreur de lecture chez
l'humain.
Le problème est lié aux mélange des conventions s ou t et n'est pas
propre à python puisque même en C on peut se retrouver avec une
indentations visuellement foireuses dans ce cas. A ce moment là les '{'
peuvent aider; mais je pense que lorsqu'un humain relis un code, il ne
regarde pas les accolades au 1er coup et se fie aux indentations en
priorité. Un code écrit sans indentation est considéré comme illisible:
Oui moi aussi je n'ai pas compris. Il y a un truc qui m'échappe dans ce qu'a dit Erwan.
Si je peux ajouter mon grain de sel. Je pense qu'il fait référence aux pbs de taille de tabulation. Ainsi sur certains outils ou terminaux le tab vaut 8 espaces, et pour d'autres 4. Au final les chaines (s=espace t=tab)
ssssssss5 et: t6
représentant la même indentation seront affichées par un terminal (ou par un outil d'édition) comme:
^ 5 ^ 6 ou: ^ 5 ^ 6
C'est à dire comme n'ayant pas "visuellement" la même indentation. Ca ne change pas la sémantique du code (les niveaux d'indentations sont identiques: 1 tabulation), mais peut induire une erreur de lecture chez l'humain.
Le problème est lié aux mélange des conventions s ou t et n'est pas propre à python puisque même en C on peut se retrouver avec une indentations visuellement foireuses dans ce cas. A ce moment là les '{' peuvent aider; mais je pense que lorsqu'un humain relis un code, il ne regarde pas les accolades au 1er coup et se fie aux indentations en priorité. Un code écrit sans indentation est considéré comme illisible:
en embarqué (par exemple), on peut devoir faire des manip 'octet', il faut juste savoir que ce n'est plus de "vrai" C.
Je ne sais pas ce que tu entends par « manip 'octet' », mais je ne vois pas pourquoi ce ne serait pas du « "vrai" C »...
Certes le code C logique (celui qu'il faut écrire) ne sera peut-être pas strictement conforme en ce sens qu'il faudra peut-être faire des impasses sur certaines architectures exotiques, et donc une éventuelle (et théorique) compilation de ce programme sur une de ces machines pourrait ne pas fonctionner... mais je ne suis pas sûr que ce soit important au final pour la manipulation des dits octets.
De plus, si tu prends la précaution de masquer les résultats avec 0x255 avant de stocker dans des variables unsigned char, ce qui ne coûte que le temps de l'écrire car la plupart des compilateurs qui optimisent vont éliminer l'opération, alors les manipulations les plus courantes resteront strictement conformes et donc --je suppose-- du vrai C.
Maintenant, si le code fait l'hypothèse que la machine est petit ou gros-boutienne, et manipule directement 4 octets d'un coup au travers d'un long, effectivement ce n'est pas (plus) du vrai C...
Antoine
Stephane Legras-Decussy écrivit :
en embarqué (par exemple), on peut devoir faire des manip 'octet', il
faut juste savoir que ce n'est plus de "vrai" C.
Je ne sais pas ce que tu entends par « manip 'octet' », mais je ne vois
pas pourquoi ce ne serait pas du « "vrai" C »...
Certes le code C logique (celui qu'il faut écrire) ne sera peut-être pas
strictement conforme en ce sens qu'il faudra peut-être faire des
impasses sur certaines architectures exotiques, et donc une éventuelle
(et théorique) compilation de ce programme sur une de ces machines
pourrait ne pas fonctionner... mais je ne suis pas sûr que ce soit
important au final pour la manipulation des dits octets.
De plus, si tu prends la précaution de masquer les résultats avec 0x255
avant de stocker dans des variables unsigned char, ce qui ne coûte que
le temps de l'écrire car la plupart des compilateurs qui optimisent vont
éliminer l'opération, alors les manipulations les plus courantes
resteront strictement conformes et donc --je suppose-- du vrai C.
Maintenant, si le code fait l'hypothèse que la machine est petit ou
gros-boutienne, et manipule directement 4 octets d'un coup au travers
d'un long, effectivement ce n'est pas (plus) du vrai C...
en embarqué (par exemple), on peut devoir faire des manip 'octet', il faut juste savoir que ce n'est plus de "vrai" C.
Je ne sais pas ce que tu entends par « manip 'octet' », mais je ne vois pas pourquoi ce ne serait pas du « "vrai" C »...
Certes le code C logique (celui qu'il faut écrire) ne sera peut-être pas strictement conforme en ce sens qu'il faudra peut-être faire des impasses sur certaines architectures exotiques, et donc une éventuelle (et théorique) compilation de ce programme sur une de ces machines pourrait ne pas fonctionner... mais je ne suis pas sûr que ce soit important au final pour la manipulation des dits octets.
De plus, si tu prends la précaution de masquer les résultats avec 0x255 avant de stocker dans des variables unsigned char, ce qui ne coûte que le temps de l'écrire car la plupart des compilateurs qui optimisent vont éliminer l'opération, alors les manipulations les plus courantes resteront strictement conformes et donc --je suppose-- du vrai C.
Maintenant, si le code fait l'hypothèse que la machine est petit ou gros-boutienne, et manipule directement 4 octets d'un coup au travers d'un long, effectivement ce n'est pas (plus) du vrai C...
Antoine
Marc Boyer
Le 31-08-2012, Samuel DEVULDER a écrit :
Le problème est lié aux mélange des conventions s ou t et n'est pas propre à python puisque même en C on peut se retrouver avec une indentations visuellement foireuses dans ce cas. A ce moment là les '{' peuvent aider; mais je pense que lorsqu'un humain relis un code, il ne regarde pas les accolades au 1er coup et se fie aux indentations en priorité. Un code écrit sans indentation est considéré comme illisible:
Sauf que n'importe quel outil sait regarder les séparateurs et générer l'indentation (avec le style qui plait au lecteur: ANSI, K&R, GNU...)
Avec python, le style est imposé par le langage.
Ca ne fait pas un argument pour ou contre, mais ça invalide la comparaison.
Marc Boyer -- À mesure que les inégalités regressent, les attentes se renforcent. François Dubet
Le 31-08-2012, Samuel DEVULDER <samuel-dot-devulder@laposte-dot-com> a écrit :
Le problème est lié aux mélange des conventions s ou t et n'est pas
propre à python puisque même en C on peut se retrouver avec une
indentations visuellement foireuses dans ce cas. A ce moment là les '{'
peuvent aider; mais je pense que lorsqu'un humain relis un code, il ne
regarde pas les accolades au 1er coup et se fie aux indentations en
priorité. Un code écrit sans indentation est considéré comme illisible:
Le problème est lié aux mélange des conventions s ou t et n'est pas propre à python puisque même en C on peut se retrouver avec une indentations visuellement foireuses dans ce cas. A ce moment là les '{' peuvent aider; mais je pense que lorsqu'un humain relis un code, il ne regarde pas les accolades au 1er coup et se fie aux indentations en priorité. Un code écrit sans indentation est considéré comme illisible:
Sauf que n'importe quel outil sait regarder les séparateurs et générer l'indentation (avec le style qui plait au lecteur: ANSI, K&R, GNU...)
omg = trolldi("Il manque le Whitesmiths dans la liste !");
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
Samuel DEVULDER
Le 07/09/2012 14:39, Marc Boyer a écrit :
(...); mais je pense que lorsqu'un _humain_ relis un code, il ne regarde pas les accolades au 1er coup et se fie aux indentations en priorité. Un code écrit sans indentation est considéré comme _illisible_:
Sauf que n'importe quel outil sait regarder les séparateurs et générer l'indentation (avec le style qui plait au lecteur: ANSI, K&R, GNU...)
Oui, mais je parlais du point de vue de la lisibilité _humaine_. Les outils se débrouillent très bien avec les changements de convention dans les tabulations. (Les exemples ci dessus montrent notamment que python différencie parfaitement le mis-alignement lors de ces mélange et que le mélange de t et s ne gène absolument pas le parseur.)
Avec python, le style est imposé par le langage.
Mon propos n’était pas un pb de style mais un pb de mélange de convention de tabulations. Cela n'est propre à aucun langage car tous ont ce problème.
Ca ne fait pas un argument pour ou contre, mais ça invalide la comparaison.
Il n'y a ni pour ni contre. Mon point de vue ne cherchait pas à comparer les langages eux-même, mais je signalais que le pb soulevé par Erwan était le mélange de convention de tabulation et cela est problématique pour tous les langages lors de la relecture par l'interface chaise-clavier (bref, par nous autres pauvres humains).
sam.
Le 07/09/2012 14:39, Marc Boyer a écrit :
(...); mais je pense que lorsqu'un _humain_ relis un code, il ne
regarde pas les accolades au 1er coup et se fie aux indentations en
priorité. Un code écrit sans indentation est considéré comme _illisible_:
Sauf que n'importe quel outil sait regarder les séparateurs et
générer l'indentation (avec le style qui plait au lecteur: ANSI,
K&R, GNU...)
Oui, mais je parlais du point de vue de la lisibilité _humaine_. Les
outils se débrouillent très bien avec les changements de convention dans
les tabulations. (Les exemples ci dessus montrent notamment que python
différencie parfaitement le mis-alignement lors de ces mélange et que le
mélange de t et s ne gène absolument pas le parseur.)
Avec python, le style est imposé par le langage.
Mon propos n’était pas un pb de style mais un pb de mélange de
convention de tabulations. Cela n'est propre à aucun langage car tous
ont ce problème.
Ca ne fait pas un argument pour ou contre, mais ça invalide
la comparaison.
Il n'y a ni pour ni contre. Mon point de vue ne cherchait pas à comparer
les langages eux-même, mais je signalais que le pb soulevé par Erwan
était le mélange de convention de tabulation et cela est problématique
pour tous les langages lors de la relecture par l'interface
chaise-clavier (bref, par nous autres pauvres humains).
(...); mais je pense que lorsqu'un _humain_ relis un code, il ne regarde pas les accolades au 1er coup et se fie aux indentations en priorité. Un code écrit sans indentation est considéré comme _illisible_:
Sauf que n'importe quel outil sait regarder les séparateurs et générer l'indentation (avec le style qui plait au lecteur: ANSI, K&R, GNU...)
Oui, mais je parlais du point de vue de la lisibilité _humaine_. Les outils se débrouillent très bien avec les changements de convention dans les tabulations. (Les exemples ci dessus montrent notamment que python différencie parfaitement le mis-alignement lors de ces mélange et que le mélange de t et s ne gène absolument pas le parseur.)
Avec python, le style est imposé par le langage.
Mon propos n’était pas un pb de style mais un pb de mélange de convention de tabulations. Cela n'est propre à aucun langage car tous ont ce problème.
Ca ne fait pas un argument pour ou contre, mais ça invalide la comparaison.
Il n'y a ni pour ni contre. Mon point de vue ne cherchait pas à comparer les langages eux-même, mais je signalais que le pb soulevé par Erwan était le mélange de convention de tabulation et cela est problématique pour tous les langages lors de la relecture par l'interface chaise-clavier (bref, par nous autres pauvres humains).
sam.
Stephane Legras-Decussy
Le 31/08/2012 12:54, Antoine Leca a écrit :
Maintenant, si le code fait l'hypothèse que la machine est petit ou gros-boutienne, et manipule directement 4 octets d'un coup au travers d'un long, effectivement ce n'est pas (plus) du vrai C...
c'est exactement ce à quoi je pensais...
Le 31/08/2012 12:54, Antoine Leca a écrit :
Maintenant, si le code fait l'hypothèse que la machine est petit ou
gros-boutienne, et manipule directement 4 octets d'un coup au travers
d'un long, effectivement ce n'est pas (plus) du vrai C...
Maintenant, si le code fait l'hypothèse que la machine est petit ou gros-boutienne, et manipule directement 4 octets d'un coup au travers d'un long, effectivement ce n'est pas (plus) du vrai C...
