systeme POSIX - Page 8

J'ai dit "des fois", c'est pas absolu, c'est selon les réglages (donc mes réglages avec xfconfig ) bien sûr....
et les drivers nvidia n'étaient pas à jour pour la 5.1 de FreeBSD, Linux est mis à jour plus souvent avec les
distrib et sait se régler tout seul.

godzil
:

BSS
: godzil > FreeBSD p0w4 !!! (Sauf qu'il veut pas X11 avec ma nvidia des fois)

ben alors DTC pasque le XFree86 des *BSD est strictement le meme que sous Linux

mais ça il va te dire qu''il le savait

croisé : donc ça a pas raté...

BSS :
J'ai dit "des fois", c'est pas absolu, c'est selon les réglages (donc mes réglages avec xfconfig ) bien sûr....

Bien sûr

et les drivers nvidia n'étaient pas à jour pour la 5.1 de FreeBSD,

ha bon ?
tu connait /usr/ports ? J'ai pas l'impression

Linux est mis à jour plus souvent avec les distrib et sait se régler tout seul.

Il sait se regler tout seul ?
Qui ??
Ta connerie ?

Non, je disais t'as pas à tripatouiller les outils en mode console quand t'install une mandrake...
Et oui, les drivers nvidia n'étaient pas à jour... Et pas inet chez moi.

et si on retournait sur un sujet plus pationant comme du C par ex

pasque tu continu a t'enfoncer grave sur tout les sujets alors restont sur un seul comme ça tu parraitra moins c*n

Oui, je vois surtout une croix rouge....

godzil :
et si on retournait sur un sujet plus pationant comme du C par ex

Ce serait pas très charitable pour snowtiger/*Silk/BSS/etc, ça

ignore autent que tu veux je me generait pas pour répondre a tout tes posts, les autres verronts toujours mes réponses

Lui aussi, puisqu'il te dé-ignore à chaque fois que tu postes.

pollux : c'est pas drôle ! il ré ignore juste après quand même ! ^^

#héhé#

t'as oublié les : ^{(c) TM} corp

godzil :
BlueSilk trouve sa trop long : ((char *str = (char *) malloc((1+strlen(txt)) * sizeof(char))==NULL)?:strcpy(str,"Tout le monde a son arbre dans ce bosquet sacré où nous mènent les rêves.");

Au fait, c'est faux : tu fais une déclaration à l'intérieur d'une expression

pas en C99 normalement

sinon considere ça comme du C++

Ni l'un ni l'autre
C'était une extension GTC à une époque, mais je l'ai retirée.

c'est totalement valide en C++

tu peut déclarer une variable ou bon te semble.

En tout cas c pas du C99. Pour le C++, je vais vérifier ça tout de suite.

Confirmation : c pas du C++ valide.

en C++

j'avais vu du code (immonde) ou le gars faisait des

for(int i=0;i<xxx;i++)
{

}

c'est assé horrible en regle général comme code

Hum
bon je sépare la déclaration alors

godzil :
en C++

j'avais vu du code (immonde) ou le gars faisait des

for(int i=0;i<xxx;i++)
{

}
c'est assé horrible en regle général comme code

C'est pas pareil. Dans ce cas-là (début d'une boucle for), le compilo attend un statement (en fait, pas n'importe lequel, mais un statement quand même). Là, tu le fais dans une expression, ce qui n'a rien à voir (et le résultat serait désastreux si un vilain programmeur voulait s'en servir pour remplacer les ({...}) du GNU C, parce qu'alors la portée serait étendue à toute la fonction et pas juste à l'expression).

Et c'est pas si horrible que ça : si tu veux déclarer une variable locale à la boucle (c'est souvent le cas pour les indices de tableaux), la solution C90 est :

...
foo(bar);
{
int i;
for (i=0;i<xxx;i++) ...;
} ...

ce qui est assez moche et en pratique décourage l'utilisation de variables dont la scope est réduite (dans la mesure du possible) à la période de validité. Donc, en C90, on fout un paquet de déclarations de variables au début de la procédure, et on les utilise tant bien que mal un peu partout en évitant les conflits et en essayant de prier pour qu'on n'utilise pas un tableau non encore initialisé. (en plus le code est plus long et on est obligé de taper le nom de la variable une fois de plus, donc j'aime pas trop)

En C++, la notion de portée des variables est encore plus problématique (parce que si une variable dure trop longtemps, elle bouffera inutilement de la mémoire parce que son destructeur n'aura pas été appelé), donc on est obligé de recourir à des solutions plus propres comme celle-là

ba de tte ma nouvelle version fait autant g33k

edit: g du mal a taper cet aprem

Encore plus efficace, mais pas portable :
char *str = (OSSetSR(0x700), strcpy(malloc(74)?:0,"Ca c'est du code portable %)")), q=OSSetSR(0);

pourquoi tu utilise OSSetSR ??

Tu es sur que sa compile avec TiGCC? #doute#

le plus simple reste quand meme

char str[] = "bouuuuuuu c'est trop simple #trigol#";

pourquoi tu utilise OSSetSR ??

Pour inhiber l'autoint 7 qui sera appelée lors de l'écriture vers NULL (et NULL+1 .. NULL+73). Sinon, Protected Memory Violation

Tu es sur que sa compile avec TiGCC? #doute#

Ben vi pkoi? Le seul doute que je pourrait éventuellement avoir serait que les vecteurs d'interruptions soient corrompus quand il n'y a pas d'autoint 7 (mais au moment de l'exécution). Je ne pense pas que ce soit le cas, mais on sait jamais...

Ben si tu laisse le code telquel
q n'est pas défini

[edit]J'avais pas vu le "pas"
Tu ne désalloues même pas l'espace pour la chaine.

Justement, q est une déclaration. Non, il n'y a pas de problème de compilation, je pense.

Et en fait pour que le code soit parfaitement correct (i.e. utilisable aussi dans un prog qui désactive les interruptions), il faudrait faire :
char _foo=OSSetSR(0x700)>>8, *str=strcpy(malloc(74)?:0,"Ca c'est du code portable %)"), _done=OSSetSR(_foo<<8);