Quelques chtittes questions de gros mauvais - Page 1

Voilà, il y a achement longtemps que j'ai pas écrit une lettre de C et je voulais créer un topic pot pourri pour poser mes question à deux balles sans devoir refaire un topic à chaque fois

Alors voilà la première:
     char message[256],*fill;      fill = &message;

Ma question est pourquoi à la compilation ai-je droit à un warning quie me dit :"Assignement from incompatible pointer type".

Il me semble pourtant avoir déclaré un tableau de 256 char et un pointeur de char, mais quand je veux faire pointer mon pointeur de char vers des chars là il me dit que c'est pas top !?!

Merci pour vos éclaircissement.

Un tableau d'octet est (presque) un pointeur sur char, donc ton &message est un superpointeur () sur char (un char** quoi).

Il ne faut pas mettre de &, car message désigne déjà une adresse.
Pour être plus exact : &message désigne l'adresse de la variable message, donc l'adresse d'un pointeur sur un char, donc c'est un pointeur sur un pointeur (char**) et non-pas un pointeur sur un caractère (char*).

Parce que message est déjà une adresse, en fait message a la même valeur que &message[0]

Edit: oula ya du monde

bon, ben j'allais faire la meme remarque : message contient l'adresse de la premiere case de ton tableau.

plus généralement, message+i represente l'adresse de la ieme case de ton tableau.

Ah ben si après ça il a pas compris

blackGhost (./6) :
Ah ben si après ça il a pas compris

^^^^ lol merci bien à tous.

Je suis vraiment trop con, c'est pas possible

et voilà déjà une autre question...

voilà mon code:
while((key != 264) && (key = fgetchar())) {           *fill++ = (char) key; }

Là je pensais pouvoir récupérer des caractères entrés sur le clavier, ce qui est le cas, mais je pensais aussi que grace à la première partie de la condition du while (key != 264) je ne récupérerai pas la touche [ESC], mais en fait je la récupère quand m^^eme... une idée?

Si je me trompe pas :

L'opération key = fgetchar() est effectuée après le test key != 264 car elle est tout simplement située après key = fgetchar(). Donc, quand l'utilisateur tape sur ESC, le code de copie (*fill++ = (char) key) est exécuté, et le test key != 264 est réalisé au tour suivant.

etchar()) && (key != 264)) { *fill++ = (char) key; }Je parie que ça s'arrange en inversant l'expression du while :while((key = fgMais c'est vraiment ambigu comme code. Je te conseille de mettre l'affectation à part. De plus, n'oublie pas de terminer la chaîne avec un zéro

Riri (./7) :
Je suis vraiment trop con, c'est pas possible

Non, c'est pas évident les pointeurs. C'est pour ça qu'ils ont à moitié disparu dans les nouveaux langages dérivés du C (Java, C#). T'inquiète

En C# on a le droit si on veut dans un bloc unsafe

Merci thibault, tu as raison... Mais j'étais pourtant persuadé que l'évaluation des expressions se faisaient dans l'ordre inverse.

D'ailleurs j'ai essayé ta solution sans conviction car j'avais cru essayé déjà, mais j'avais du faire une erreur quelque part car ça ne marchait pas mieux

Sinon tu as raison de dire que c'est ambigu comme code, mais c'est tout le charme du C et c'est pour celà qu'aujourd'hui j'avais envi de coder en C et pas en ASM

./11 > L'évaluation se fait de gauche à droite. Attention ! Dans le cas d'un ET (&&) , si la première expression est fausse, la deuxième ne sera pas évaluée. Ceci peut conduire à certaines surprises, surtout si l'on fait appel à une fonction dans le test. De même, pour un OU (||), si la première expression est vraie, la deuxième ne sera pas évaluée.

ok merci ça me revient maintenant, et c'est ma foie plutot logique

Riri (./13) :
ok merci ça me revient maintenant, et c'est ma foie plutot logique

Encore un alcoolique !

lol -e

Si tu veux que tout soit évalué, la méthode suivante marche théoriquement, mais les compilateurs ne voient peut-être pas la subtilité et se plantent en optimisant le code. A essayer :

while(!!(key = fgetchar()) & !!(key != 264)) 
{ 
          *fill++ = (char) key; 
}

enfait je ne vaux pas que tout soit évalué...

Ce que je veux c'ets d'abord savoir si la touche appuyé est la touche esc; si non alors j'enregistre le charactère dans ma chaine de caractère.

Ce que tu peux faire, pour que ce soit plus clair, c'est :

while((key = fgetchar()) != 264)  
{  
          *fill++ = (char) key;  
}

A moins que la touche ENTER renvoit le code 0 ?

Thibaut (./18) :
Ce que tu peux faire, pour que ce soit plus clair, c'est :

while((key = fgetchar()) != 264)  
{  
          *fill++ = (char) key;  
}

A moins que la touche ENTER renvoit le code 0 ?

c'est ce que j'avais fait au début, mais je trouve ça plus marrant de ne pas faire comme ça, c'est pour coller un peu plus au principe qui dit que le C est Read Only^^. Et puis habituellement je code en asm, et ça prends de la place alors là ça m'amusait de condenser.

Martial> je voulais faire juste un petit truc de rien du tout avec pas mal d'I/O alors le C simple et rapide...

Edit: pour rajouter la dernière ligne

"read only" ?

Nan ce que je veux dire c'est que à force de condenser, ça devient illisible et pas maintenable...

Donc Write Only

arf lol pourquoi je dors si peu moi

Ximoon (./2) :
Un tableau d'octet est (presque) un pointeur sur char, donc ton &message est un superpointeur () sur char (un char** quoi).

Non, ce n'est pas un char **. C'est encore un animal différent, un char (*)[256]. Alors qu'assigner un char ** à un char * est une erreur fatale (ça va passer avec un warning aussi, mais boguer grave en temps d'exécution), ici le warning est le seul problème, parce qu'un char (*)[256] n'est pas si différent que ça d'un char *. (Ceci dit, le warning est raison suffisante pour corriger le problème.)

L'adresse contenue dans un char ** est l'adresse d'un pointeur (de type char *). L'adresse contenue dans un char (*)[256] est l'adresse du premier char du tableau de 256 chars.

Cette différence est importante quand on veut faire un tableau à plusieurs dimensions: un char ** revient à la représentation style Java (tableau de pointeurs), un char (*)[n] à une représentation contiguë en mémoire (donc plus efficace, une seule allocation à faire).

Le pointeur obtenu par le decay (conversion automatique tableau->pointeur sous certains contextes, c'est ça qui permet d'utiliser le char [256] directement comme un char * sans aucune conversion) d'un char *(x[m]) est un char **px. Le pointeur obtenu par le decay d'un char y[m][n] est un char (*py)[n].

(d'où les "presque", je me doutais que j'allais être corrigé de la sorte )

Normalement en C la fin de chaine c'est '\0'?

Pourquoi lorsque je le met après ce que j'ai récupéré sprintf où drawstr ne le voit pas?

j'ai essayé par deux méthodes différentes, soit avec Strcat soit en écrivant directement à l'aide du pointeur fill en fin de chaine.

Evidemment avec strcat y pouvais pas savoir où s'arretait la première chaine puisque je voualais justement la fermer... mais la je comprends pas pourquoi la deuxième sollution ne marche pas:

*fill = "\0";

Rha j'ai enfin trouvé, mais je pige pas trop pour quoi...


Il faut faire :

*fill = \0;

si qu'elqun peut m'éclairer ça serait gentil, en général j'aime quand m^^eme comprendre ce que je fais.

fill étant un pointeur de char, j'essayais de lui passer un char, mais j'avais un warning, raison pour laquelle j'ai tester sans les quotes, mais bon je comprends toujours pas.

Riri (./28) :
Normalement en C la fin de chaine c'est '\0'?

oui

Pourquoi lorsque je le met après ce que j'ai récupéré sprintf où drawstr ne le voit pas?

j'ai essayé par deux méthodes différentes, soit avec Strcat soit en écrivant directement à l'aide du pointeur fill en fin de chaine.

Evidemment avec strcat y pouvais pas savoir où s'arretait la première chaine puisque je voualais justement la fermer... mais la je comprends pas pourquoi la deuxième sollution ne marche pas:

*fill = "\0";

ça veut dire que "fill" ne pointe sur le bon octet.
En général tu as pas besoin de mettre le caractère de fin de chaine à la main.

En plus, c'est dangereux. Exemple, ne pas faire:

char str[ 3 ] = {'a','b','c'};
char *fill = str[ 3 ];*fill = 0;// <=plantage