comment colorier un printf?

Version imprimable

09/12/2009, 21h42
waldomania

comment colorier un printf?

Bonjour,

comment colorier un printf?

merci
09/12/2009, 22h12
LinuxUser
Il semblerait que se soit

Code:

033[couleur_police;couleur_fondm

Exemples :
Code:

1 2 3 printf ("\033[32;40m"); printf ("\033[0m");
Le "m" sert à fermer la sequence.
09/12/2009, 22h22
Melem

printf ne fait qu'envoyer du texte sur le flux de sortie standard, elle (ni aucune fonction de la bibliothèque standard) ne permet pas de contrôler le périphérique qui se trouve derrière le flux à moins que le périphérique supporte des séquences spéciales (par exemple les séquences d'échappement ANSI) qu'on peut lui envoyer sous forme de texte. Normalement, tu dois appeler les fonctions de ton système mais il y a aussi des bibliothèques portables qui encapsulent ces fonctions, par exemple PDCurses.

Juste par curiosité, quel est ton système (DOS ? Windows ? Linux ? MacOS X ?) ?
09/12/2009, 22h26
Melem
Citation:
Envoyé par juve1897

Il semblerait que se soit

Code:

033[couleur_police;couleur_fondm

Exemples :

Code:

1 2 3 printf ("\033[32;40m"); printf ("\033[0m");

Le "m" sert à fermer la sequence.
Ca ne marche que si le terminal supporte les séquences ANSI VT100/VT52, ce qui est le cas sous DOS et Linux mais ce n'est pas portable.
10/12/2009, 02h16
LittleWhite

J'ai un fichier pseudo plateforme indépendant pour la coloration des messages ( printf ). Mais j'utilise une feinte, celle d'une compilation conditionnel ( ou autrement appelée #ifdef blocs ) pour savoir si je suis sous windows ou unix ... comme ça je change la méthode de coloration. Jusqu'a présente ça marche.
10/12/2009, 16h02
Melem

Citation:

Envoyé par LittleWhite

J'ai un fichier pseudo plateforme indépendant pour la coloration des messages ( printf ). Mais j'utilise une feinte, celle d'une compilation conditionnel ( ou autrement appelée #ifdef blocs ) pour savoir si je suis sous windows ou unix ... comme ça je change la méthode de coloration. Jusqu'a présente ça marche.

C'est déjà pas mal mais d'habitude on ne fournit qu'un seul fichier d'en-tête donc on utilise les mêmes fonctions pour n'importe quel système. C'est le fichier avec lequel il faut se lier (le .lib sous Windows) qu'on change chaque fois qu'on change de système et bien entendu, les sources des ces différents libs sont plateforme-dépendantes. Mais c'est là justement l'intérêt de la notion d'interface : on définit l'interface (le prototype) d'une fonction, qui peut souvent être plateforme-indépendante, et on cache l'implémentation, qui peut être plateforme-dépendante.
11/12/2009, 00h47
LittleWhite

Je ne sais pas si je me suis un peu mal expliqué, ou si je vous ai pas compris. Mais quelque soit le système j'ai les mêmes fonctions (ainsi que les même codes de couleurs) ( point de vue développeur). L'implémentation derrière change, selon les bloc de #ifdef.
Donc l'utilisateur ( enfin le développeur qui utilise mon truc) voit toujours les mêmes fonctions et les même noms de macro, par contre, il ne voit pas que le code qui permet de faire ce qu'il veut a changer :D.
C'est ce que j'appelle une interface

Oui j'ai compris. Mais ce que je voulais dire c'est plutôt que de faire :

Code:

1
2
// header.h
int f(void);

Code:

1
2
3
4
5
6
7
8
9
// source.c
int f(void)
{
    #if TARGET == 1
    return 1;
    #elif TARGET == 2
    return 2;
    #endif
}

Mieux vaut faire :

Code:

1
2
// header.h (commun a source-target1.c et source-target2.c)
int f(void);

Code:

1
2
3
4
5
// source-target1.c
int f(void)
{
    return 1;
}

Code:

1
2
3
4
5
// source-target2.c
int f(void)
{
    return 2;
}

C'est la manière habituelle de faire en C.

12/12/2009, 01h04
LittleWhite

Je préfère aussi la deuxième méthode.
Mais le choix est donc fait par le Makefile ? ( le choix du fichier .c )
12/12/2009, 01h15
Melem

Bien entendu. Et la cible est donnée en argument de la commande make. Par exemple make target1.