Apprendre le C - Page 2

SaveScrState ne sauvegarde pas le contenu de l'écran, juste quelques données du style où le dernier caractère imprimé était...

si tu veux simplement restaurer l'écran quand le programme est terminé (i.e. pour pas supprimer la barre d'état), rajoute #define SAVE_SCREEN au début du programme, sinon regarde du côté de LCD_save/LCD_restore...

pouvez-vosu m'indiquer les autres define sous C ou un lien où je peux les trouver ?

merci Grand Maître Pollux !

Salut à tous !
Je serai très reconnaissant si quelqu'un me mentionne la foncion C qui efface l'écran (autre que clrscr(), car celle-ci ne fonctionne pas dans Visual Studio).
Merci d'avance

system("cls") pour la ligne de commandes sous windows, mais tu es completement hors sujet je crois

heu

'system("cls")' est ultra spécifique et n'est pas du tout standard..

D'ailleurs le C en lui meme ne propose *PAS* de fonction pour effacer l'ecran..

D'ailleurs je déconseille au maximum d'utiliser 'system' pour tout ce qui peut etre fait avec la libc standard et/ou d'autres lib

Godzil :
'system("cls")' est ultra spécifique et n'est pas du tout standard..

ben oui, mais il dit qu'il travaille sous Visual Studio, donc...

D'ailleurs je déconseille au maximum d'utiliser 'system' pour tout ce qui peut etre fait avec la libc standard et/ou d'autres lib

forcément, mais comme tu le dis toi même :

D'ailleurs le C en lui meme ne propose *PAS* de fonction pour effacer l'ecran..

En meme temps ça depend ce qu'il entend par "effacer l'ecran"

oui, c'est pour ça que j'ai précisé que c'était pour la ligne de commande

En ligne de commande, il y a les escape sequences ANSI. Elles fonctionnent parfaitement à peu près partout, sauf certaines versions et configurations des pauvres terminaux Windows qui ne respectent pas les standards, comme d'hab
#define ESC_CLRSCR "\033[2J"
#define ESC_NORMAL "\033[0m"
#define ESC_BOLD "\033[1m"
#define ESC_UNDERLINED "\033[4m"
#define ESC_BLINK "\033[5m"
#define ESC_INVERT "\033[7m"
#define ESC_FG_BLACK "\033[30m"
#define ESC_FG_RED "\033[31m"
#define ESC_FG_GREEN "\033[32m"
(et cinq autre couleurs)
#define ESC_BG_BLACK "\033[40m"
#define ESC_BG_RED "\033[41m"
#define ESC_BG_GREEN "\033[42m"
(et cinq autres couleurs)

En notation hexa: "\x1B[0m".

Elles s'utilisent de la façon suivante: printf(ESC_FG_BLACK ESC_NORMAL);

*normalement* tu n'as pas besoin de sequences ANSI pour effacer un terminal,

Envoyer CTRL+L (donc le caractere ASCII 12 ou 0xB) *devrait* effacer le terminal...

Lionel Debroux :
Elles fonctionnent parfaitement à peu près partout, sauf certaines versions et configurations des pauvres terminaux Windows qui ne respectent pas les standards, comme d'hab

Je serais curieux de savoir pour quelle raison "les" termin"aux" Windows (pourquoi un pluriel ?) auraient eu à respecter ça; quoi qu'il en soit puisque son programme semble être pour Windows, cette solution n'a pas beaucoup d'interêt (peut-être qu'il y a moyen de faire accepter ça à cmd, mais par défaut ça va afficher n'importe quoi, et certainement pas effacer l'écran ou changer la couleur).

./43> Pour que les programmes soient plus portables ?

Quels programmes ? Jusqu'à maintenant (on verra ce qu'il se passe avec Microsoft Powershell), les programmes qui se lancent dans une fenêtre DOS sous Windows, ça fait pas très naturel... je veux dire par là que quand on veut faire un programme pour Windows, on essaie de se plier un minimum à l'environnement et on fournit une interface graphique; pour moi un truc qui se lance en ligne de commande (sous Win hein), c'est soit parceque c'est une version non définitive, soit ça part à la poubelle :/

Les terminaux de Windows NT supportent les codes ANSI. POur ce qui est de DOS, il faut charger ANSI.SYS pour que ça marche.

#42: ben, pour faire comme la plupart du reste du monde (en général POSIX / Unix): respecter les standards, des standards qui sont accessoirement extrêmement vieux ('70 ou '80 !). Ce que Windows fait rarement, il est vrai...
Ca fait depuis les années 1980 que les Unix disposent de systèmes de fichiers à fragmentation faible... et que celui de Vista n'en sera toujours pas un (puisque c'est un défragmenteur qui tourne en arrière-plan qui fait le boulot, et non pas un système de fichiers bien pensé...).

> POur ce qui est de DOS, il faut charger ANSI.SYS pour que ça marche.
En effet, c'est pour ça que j'écrivais que ça dépendait des configurations. Mais je n'ai jamais réussi à le mettre sous le Windows ME qui fonctionne toujours à peu près bien chez moi...

Heuuuu la NTFS est bcp plus proche d'un FS ala unix que ce que tu crois...

Windows n'utilise plus la FAT depuis longtemps... (enfin on peut tjrs mais ce n'est pas conseillé et de toute maniere, microsoft force a utiliser la NTFS pour les "gros" disques, enfin grosses partitions)

On peu défragmenter n'importe quel FS, qu'il soit ext2, ReiserFS, HFS, NTFS, ...

Lionel Debroux
: #42: ben, pour faire comme la plupart du reste du monde (en général POSIX / Unix): respecter les standards, des standards qui sont accessoirement extrêmement vieux ('70 ou '80 !). Ce que Windows fait rarement, il est vrai...

bah heu... oui, c'est si étonnant ? effectivement Windows ne respecte pas les standards Unix, bien vu, mais ... c'est normal non ?

Bah oué, mais c'est chiant. Ça oblige à répéter les choses.

ça n'oblige rien du tout, c'est toi qui choisis de faire quelque chose sur deux systèmes qui n'ont pas les mêmes standards (et qui n'ont jamais été conçus pour les avoir); personellement je n'ai absolument aucune envie que Windows se rapproche d'Unix, et je suppose que ceux qui utilisent Unix pensent la même chose dans l'autre sens, tant pis si ça fait du boulot en plus pour les programmeurs...

Ben c'est dommage, c'est tout.
C'est tout de même plus pratique si les gens coopèrent au lieu d'être en compétition.

Surtout qu'il existe des librairie d'abstraction pour les deux systemes (par exemple)

Sasume
: C'est tout de même plus pratique si les gens coopèrent au lieu d'être en compétition.

"pratique" ça dépend pour qui (perso je me place d'un point de vue utilisateur en fait, donc que ça soit plus facile à coder... mouais, peu importe), mais je ne suis pas sûr du tout que supprimer la concurence soit une bonne chose; au moins ça pousse d'un coté comme de l'autre à s'améliorer, il n'y a pas de meilleure motivation ^^

C'est vrai... Tu marques un point.

bob > ben a priori un terminal c'est pas uniquement fait pour exécuter des commandes en local, c'est aussi fait pour exécuter des commandes à distance (genre via telnet/ssh), donc c'est pas tellement une question de portabilité des programmes pour moi, c'est qu'il faut bien qu'il respecte un minimum le standard pour que quand tu lances ton appli unix ou n'importe quoi dans ton terminal windows ça puisse t'afficher quelque chose de correct...

> Heuuuu la NTFS est bcp plus proche d'un FS ala unix que ce que tu crois...
Il a effectivement quelques features de sécurité et de permissions, mais mon propos est qu'il est facile de le faire fragmenter énormément (certes, un peu moins que FAT). J'ai vu un disque ultra-fragmenté après utilisation intensive de logiciels P2P sur quelques jours... C'est beaucoup plus dur avec les systèmes de fichiers classiques depuis une vingtaine d'années sur les Unix

> mais je ne suis pas sûr du tout que supprimer la concurence soit une bonne chose; au moins ça pousse d'un coté comme de l'autre à s'améliorer, il n'y a pas de meilleure motivation ^^
Hmm. Pas faux, mais... la concurrence n'est pas forcément une bonne chose non plus.
Il y avait une concurrence féroce entre les différents Unix propriétaires et les boîtes qui les fabriquaient, créant de nombreuses incompatibilités. C'était un problème qu'il n'y avait pas avec Windows, bien que lui aussi soit propriétaire et payant, et utilisé pour le verrouillage sur un vendeur ("vendor lock-in").
Ces Unix propriétaires ont à peu près tous disparu (sauf niche, et encore...), au profit de (GNU/)Linux, dans le sens où ils ne sont plus développés activement. Seul (open)Solaris s'en sort un peu mieux...

Sally
: bob > ben a priori un terminal c'est pas uniquement fait pour exécuter des commandes en local, c'est aussi fait pour exécuter des commandes à distance (genre via telnet/ssh)

ssh sous Windows ? :/ enfin perso si je veux executer des commandes à distances, je pense que je trouverai un outil adapté à Windows plutôt que des technologies qui n'y sont pas adaptées (enfin c'est moins vrai pour telnet, mais par contre ssh...)

Lionel Debroux :
Hmm. Pas faux, mais... la concurrence n'est pas forcément une bonne chose non plus.
Il y avait une concurrence féroce entre les différents Unix propriétaires et les boîtes qui les fabriquaient, créant de nombreuses incompatibilités. C'était un problème qu'il n'y avait pas avec Windows, bien que lui aussi soit propriétaire et payant, et utilisé pour le verrouillage sur un vendeur ("vendor lock-in"). Ces Unix propriétaires ont à peu près tous disparu (sauf niche, et encore...), au profit de (GNU/)Linux, dans le sens où ils ne sont plus développés activement. Seul (open)Solaris s'en sort un peu mieux...

bien sûr qu'il s'en sort mieux, je vois mal comment ça pourrait être l'inverse; si il y avait un seul système tout le monde l'aurait, quelque part on peut considérer ça comme "s'en sortir mieux" aussi, mais tu crois vraiment que c'est une bonne idée ?
(btw on s'éloigne pas mal du sujet, la question n'est pas "un monopole est-il une bonne chose ?", je pense que la réponse est évidente, mais "Windows est-il supposé se plier aux normes imposées par Unix ?"; pour moi la phrase seule suffit à répondre clairement "non, il n'y a aucune raison".)

> je pense que la réponse est évidente, mais "Windows est-il supposé se plier aux normes imposées par Unix ?"; pour moi la phrase seule suffit à répondre clairement "non, il n'y a aucune raison".
Rien ne l'y oblige effectivement... mais ça serait mieux pour tout le monde (enfin, presque...), programmeurs et utilisateurs (pas ceux de Microsoft, évidemment...).

encore une fois : programmeurs oui je suis d'accord, mais utilisateurs... franchement si c'est pour se retrouver avec davantage de programmes en ligne de commande, ce n'est pas mieux amha (non, les gens normaux n'aiment pas taper des lignes de commandes et préferent de loin avoir des interfaces graphiques les moins complexes possibles); dans le peu de codeurs qui auront le courage de faire une interface graphique quand ils porteront leurs programmes Unix sur Windows, même si ça représente une faible minorité, ça sera toujours ça de gagné.