[débutant] 1er programme, j'aimerais vos commentaires.

Beware wrote:

Bonjour,

J'ai pas trop eu le temps de bosser sur mon programme aujourd'hui.
J'ai quand même un peu cherché sur l'utilisation de getchar() et j'en
suis arrivé la pour l'instant :

int main()
{
int c;
int etat = 0;

puts("quel est votre choix : ");

do
{
c = getchar();
etat = 0;

if ( (c >= 97 && c <= 122) || (c >= 65 && c <= 90))

Si tu t'en tiens à de l'ASCII et autres trucs pas trop exotiques, voici
quelque-chose d'utile qui améliore la lisibilité et la maintenance :

if (c >= 'a' && c <= 'z' || c >= 'A' && c <= 'Z')

(j'ai mis à ma sauce, libre à toi de remettre les parenthèses !).

Mais il y a encore beaucoup mieux pour ce cas précis :

if (isalpha(c))

Standard et concis (et accessoirement très portable car non-limité à
l'ASCII et ses cousins).


--
Alex

Marc Espie <espie@lain.home> wrote:

>
>Quel serait ton conseil alors ?

Ignorer l'avertissement et envoyer gcc se faire cuire un oeuf.

Je savais que gcc pouvait fair beaucoup de chose, mais cuire un oeuf....
non... :)
--
Membre de MacInside
http://www.macinside.be/

Le 16/03/2009 22:49, Beware écrivit :

if ( (c >= 97 && c <= 122) || (c >= 65 && c <= 90))

Pourquoi compares-tu c aux caractères â, ä, à, á, ã, ç, ., <, (, + etc.?


Car c'est ce à quoi cela correspond sur l'AS400 qui est ici...


De plus, sur l'AS400 les lettres 'a' à 'i' sont entre 0x81 et 0x89, 'j'
à 'r' entre 0x91 et 0x99, 's' à 'z' entre 0xA2 et 0xA9 (et non ce n'est
pas un hasard si cela suit les codes des cartes perforées), 'A' à 'I'
entre 0xC1 et 0xC9 etc. Autrement dit, le test d'un seul tenant ne va
pas marcher.

Donc il faut absolument suivre le conseil d'Alexandre et utiliser
isalpha(c), ce que tu faisais dans les premières versions de ton code.


Antoine

Antoine Leca <root@localhost.invalid> writes:

Le 16/03/2009 22:49, Beware écrivit :
> if ( (c >= 97 && c <= 122) || (c >= 65 && c <= 90))

Pourquoi compares-tu c aux caractères â, ä, à, á, ã, ç, ., <, (, + etc.?


Car c'est ce à quoi cela correspond sur l'AS400 qui est ici...

Tiens, puisque tu as ce genre de bebete un peu etrangere a ma culture, je
me demandais comment les locales pour ces machines traitaient en pratique
les jeux etendus de plus de 256 caracteres. Qu'est-ce qui est utilise
comme charset, et comme code multibytes? Ma comprehension des contraintes
me laisse penser que je ne connais pas de charset qui les respecte toutes
(bon, c'est pas comme si tout le monde les respectait -- l'utilisation
d'UTF-16 dans wchar_t me semble non conforme, flute le texte est different
entre C et C++... je ne suis pas sur qu'en C c'est non conforme tout compte
fait)

A+

--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Le 17/03/2009 13:35Z, Jean-Marc Bourguet écrivit :

Antoine Leca <root@localhost.invalid> writes:

Le 16/03/2009 22:49, Beware écrivit :

if ( (c >= 97 && c <= 122) || (c >= 65 && c <= 90))

Pourquoi compares-tu c aux caractères â, ä, à, á, ã, ç, ., <, (, + etc.?

Car c'est ce à quoi cela correspond sur l'AS400 qui est ici...

Tiens, puisque tu as ce genre de bebete un peu etrangere a ma culture, je
me demandais comment les locales pour ces machines traitaient en pratique
les jeux etendus de plus de 256 caracteres.

Je dois dire qu'en C, je n'en sais rien.
Il est clair qu'on utilise des multibytes très semblables aux autres
(donc pas Unicode, deux versions de chinois sans rapport entre elles,
etc.) mais il est clair aussi que les outils MBCS semblent différents
des outils SBCS, ou en tout cas l'étaient encore il n'y a pas longtemps,
la dernière fois qu'ils ont révisés les docs...

J'essaye déjà (uniquement quand j'ai un peu de temps) de faire joujou
avec les jeux de caractères indiens, qui n'ont pas le problème du
multibytes mais pour lesquels les lettres sont essentiellement de
largeur variable (il y a même des lettres qui _s'insèrent_ avant les
lettres précédentes, ainsi une syllable comme "bli" apparaît
visuellement comme [bil]), ce qui en fait un challenge intéressant sur
un terminal 5250 qui est comme le VT100, à chasse fixe...


Antoine

Antoine Leca <root@localhost.invalid> writes:

Le 17/03/2009 13:35Z, Jean-Marc Bourguet écrivit :
> Antoine Leca <root@localhost.invalid> writes:
>
>> Le 16/03/2009 22:49, Beware écrivit :
>>> if ( (c >= 97 && c <= 122) || (c >= 65 && c <= 90))
>> Pourquoi compares-tu c aux caractères â, ä, à, á, ã, ç, ., <, (, + etc.?
>>
>> Car c'est ce à quoi cela correspond sur l'AS400 qui est ici...
>
> Tiens, puisque tu as ce genre de bebete un peu etrangere a ma culture, je
> me demandais comment les locales pour ces machines traitaient en pratique
> les jeux etendus de plus de 256 caracteres.

Je dois dire qu'en C, je n'en sais rien.

Il doit avoir des gens qui le font, a regarder la modif introduite dans TC2
-- permettre aux wchar_t d'avoir des valeurs numeriques differentes des
char correspondant pour les caracteres du jeu de base -- et corrigee dans
TC3 -- trop de code depend de ca, c'est autorise uniquement si une macro
est definie pour permettre aux gens de se blinder.

Il est clair qu'on utilise des multibytes très semblables aux autres
(donc pas Unicode, deux versions de chinois sans rapport entre elles,
etc.)

(Purement pour ma culture) C'est de l'ISO 2022 ou encore des choses
differentes?

mais il est clair aussi que les outils MBCS semblent différents des
outils SBCS, ou en tout cas l'étaient encore il n'y a pas longtemps, la
dernière fois qu'ils ont révisés les docs...

J'essaye déjà (uniquement quand j'ai un peu de temps) de faire joujou
avec les jeux de caractères indiens, qui n'ont pas le problème du
multibytes mais pour lesquels les lettres sont essentiellement de largeur
variable (il y a même des lettres qui _s'insèrent_ avant les lettres
précédentes, ainsi une syllable comme "bli" apparaît visuellement comme
[bil]), ce qui en fait un challenge intéressant sur un terminal 5250 qui
est comme le VT100, à chasse fixe...

J'ai lu des choses sur ce genre de manip dans le bouquin de Yannis sur les
fontes. Mais il etait dans un contexte OpenType -- un tout petit peu
different d'un terminal classique (il me semble me souvenir de VTxxx
capables d'afficher des caracteres en double largeur; OK pour les
ideogrammes, mais pour les ecritures indiennes, ca n'aide pas).

A+

--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Le 17/03/2009 16:44Z, Jean-Marc Bourguet écrivit :

Antoine Leca <root@localhost.invalid> writes:

Le 17/03/2009 13:35Z, Jean-Marc Bourguet écrivit :

Antoine Leca <root@localhost.invalid> writes:

Le 16/03/2009 22:49, Beware écrivit :

if ( (c >= 97 && c <= 122) || (c >= 65 && c <= 90))

Pourquoi compares-tu c aux caractères â, ä, à, á, ã, ç, ., <, (, + etc.?

Car c'est ce à quoi cela correspond sur l'AS400 qui est ici...

Tiens, puisque tu as ce genre de bebete un peu etrangere a ma culture, je
me demandais comment les locales pour ces machines traitaient en pratique
les jeux etendus de plus de 256 caracteres.

Je dois dire qu'en C, je n'en sais rien.

Il doit avoir des gens qui le font, a regarder la modif introduite dans TC2
-- permettre aux wchar_t d'avoir des valeurs numeriques differentes des
char correspondant pour les caracteres du jeu de base -- et corrigee dans
TC3 -- trop de code depend de ca, c'est autorise uniquement si une macro
est definie pour permettre aux gens de se blinder.

Ah tiens, je n'avais pas remarqué que le comité avait tué cette modif'
dans TC3.
Oui, cette modif' vient bien d'une demande IBM ; et à l'époque, je
n'avais pas trouvé cela sexy, mais alors pas du tout, mais j'étais un
peu seul... Bon, cela montre au moins que le comité sait revenir sur une
décision erronée.

Il est clair qu'on utilise des multibytes très semblables aux autres
(donc pas Unicode, deux versions de chinois sans rapport entre elles,
etc.)

(Purement pour ma culture) C'est de l'ISO 2022 ou encore des choses
differentes?

Non, c'est plutôt le même genre que les MBCS que l'on trouve sur Mac,
Microsoft ou *nix ; sauf que (si je me souviens bien) ils utilisent un
jeu de base correspondant à l'EBCDIC 037 (l'américain), ou bien ils ont
le choix entre ce truc-là et le MBCS « habituel » genre Shift-JIS (c'est
je crois ce qui se passe pour le japonais) ; mais ne te fie pas à moi,
il vaut infiniement mieux vérifier par exemple en cherchant dans les
notes de Ken Lunde sur CJK.

J'ai lu des choses sur ce genre de manip dans le bouquin de Yannis sur les
fontes. Mais il etait dans un contexte OpenType

Les polices indiennes en OpenType, c'est _très_ spécifique.

(il me semble me souvenir de VTxxx
capables d'afficher des caracteres en double largeur;

Yep. Il y a aussi (c'est logique) des PC qui sav[ai]ent faire cela en
câblé et en mode texte pur, le chip vidéo ramasse deux caractères,
adresse une ROM de génération de caractères très différente, et passe au
RAMDAC successivement les parties gauche et droite de l'idéogramme, et
cela le fait.

OK pour les
ideogrammes, mais pour les ecritures indiennes, ca n'aide pas).

Non ;-). Je ne connais aucun terminal qui fabrique des caractères
indiens en mode texte (et ce serait probablement horrible du fait des
différences de chasse pour la plupart des écritures). Le truc qui doit
être le plus approchant est probablement celui de GIST, un bidule
hardware utilisé entre autres sur des cartes PC et des terminaux genre
VT, mais je n'en ai jamais vu et je ne sais pas comment cela marche
réellement, en particulier je ne sais pas s'ils sont en mode texte
(générateur de caractères) ou APA (all-point-addressable, le mode
graphique des Xterm et autres Notepad). Et je pencherais plutôt pour le
second.


Antoine

Bonjour a tous,

Ca m'a pris un peu de temps d'apporter l'ensemble des modifications
dont nous avons parlé ici. Mais je crois y être arrivé.
Alors :
- j'ai réduit la boucle do-while de la fonction main, en une simple
appel de fonction a chaque partie.
- j'utilise désormais deux fonctions de saisie (une pour les chiffres
et une pour les lettres) n'utilisant que getchar().
- j'ai donc changé également le typage de certaines variables pour
les rendre compatible avec le getchar(), notamment, l'ensemble des
lettres jouees et la lettre en cours de test
- l'ensemble des lettres jouées a été augmenté pour correspondre a ux
nombres réels de lettres jouables par le joueurs. Utilisation donc
d'un nouveau calloc et d'une nouvelle variable qui compte le nombre de
lettre jouées.
- j'ai découpe le fichier en pendu.c en plusieurs fichiers qui
regroupe des fonctions similaires. Ce n'est pas forcement d'une
utilité grandiose sur un programme aussi petit, mais c'était "juste"
pour m'amuser.
- chaque fichier n'inclut que le "pendu.h". Tous les #include
nécessaire au programmes y sont inclus (est-ce une bonne chose?).
- appel de la fonction vide_buffer() après à la fin des fonctions de
saisie.
- ajout d'une nouvelle entrée dans le menu rejouer. Il est désormais
possible de rejouer directement en gardant le même niveau de
difficulté.
- changement de l'initialisation en début de partie suivant le choix
du joueur pour rejouer
- ajout d'un entete sur chaque fichier.

Voila en gros les modifications que j'ai apporté. Il doit encore y
avoir des bugs et des choses à améliorer j'en suis convaincu et je m'y
attends.

Les choses que je voudrais améliorer :
- implanté des messages d'erreurs lors de la saisie des chiffres du
menu.
- pouvoir mettre en œuvre les accents dans ces mêmes messages.
- pas vraiment lié au programme directement, voir les makefile.
- (pour l'instant c'est tout).

Les fichiers sont toujours disponibles ici :
http://beware007.free.fr/Projet_C/Pendu/

In article <264a3a78-43c7-4c52-91e0-84da267018f9@o11g2000yql.googlegroups.com>,
Beware <mathieu.hedard@gmail.com> wrote:

- chaque fichier n'inclut que le "pendu.h". Tous les #include
nécessaire au programmes y sont inclus (est-ce une bonne chose?).

Non, c'est une tres mauvaise idee. Ca passe tres mal a grande echelle.
Vu que le C a un seul espace de nom, et des macros, sur un gros programme,
tu vas toujours avoir des collisions a la con sur certains systemes (parce
que certains systemes ne sont pas tres "propres" cote entetes, souvent), et
parfois tu vas avoir des problemes d'ordre d'inclusion (seuls les entetes
C ISO sont garantis a peu pres corrects de ce point de vue).

Meme si c'est un peu gonflant, c'est toujours une bonne idee de mettre
tes entetes le plus a plat possible: c'est un peu chiant pour l'ecriture
initiale, mais ca te gagne un temps fou des que tu tombes sur un petit
probleme de collision de macros/d'ordre d'inclusion... sans compter que
ca te permet de n'inclure que ce que tu utilises dans un fichier C donne,
et a terme, de "voir" un peu mieux quelles sont les dependances au sein
de ton programme...

On 18 mar, 23:55, es...@lain.home (Marc Espie) wrote:

In article <264a3a78-43c7-4c52-91e0-84da26701...@o11g2000yql.googlegroups .com>,

Beware  <mathieu.hed...@gmail.com> wrote:
> -  chaque fichier n'inclut que le "pendu.h". Tous les #include
>nécessaire au programmes y sont inclus (est-ce une bonne chose?).

Non, c'est une tres mauvaise idee. Ca passe tres mal a grande echelle.
Vu que le C a un seul espace de nom, et des macros, sur un gros programme ,
tu vas toujours avoir des collisions a la con sur certains systemes (parc e
que certains systemes ne sont pas tres "propres" cote entetes, souvent), et
parfois tu vas avoir des problemes d'ordre d'inclusion (seuls les entetes
C ISO sont garantis a peu pres corrects de ce point de vue).

Meme si c'est un peu gonflant, c'est toujours une bonne idee de mettre
tes entetes le plus a plat possible: c'est un peu chiant pour l'ecriture
initiale, mais ca te gagne un temps fou des que tu tombes sur un petit
probleme de collision de macros/d'ordre d'inclusion... sans compter que
ca te permet de n'inclure que ce que tu utilises dans un fichier C donne,
et a terme, de "voir" un peu mieux quelles sont les dependances au sein
de ton programme...

Bonjour,
D'accord c'est noté et changé.
J'ai également rajouté un "rapide" makefile. J'entends par rapide, une
version simple.