[RESOLU] arrachage de cheveux sur les pointeurs

[GROS_FAIGNAN]

Expliqué autrement : un pointeur n'est qu'un numéro (généralement un entier (donc quatre octets), qui va désigner un emplacement dans la mémoire du programme), il a donc toujours la même taille ^^

d'accord mais je vois pas pourquoi strlen (prenant un long[tableau] (donc un const long *) en entré) me renverrait la taille en octet de mon pointeur ???

Sinon pour ton str_comp je ne pense pas que ça soit correct. Si tu veux faire exactement comme strcmp, il faut que le résultat soit inférieur à 0 si la première chaîne est inférieure à le seconde. Or ça ne sera pas le cas dans ta version :8

la d'accord puisque effectivement ma fonction renvoie le nombre de caractère identique jusqu'au premier différent

ma fonction char_comp renvoie bien un nombre negatif si string1<string2 (mais c'est de ma faute, j'ai oublié de remplacé nouveau par strlen... , forcement a lire sa devait etre un peut )

Je pense qu'il voulait mettre l'étoile en gras

sa c possible

Pour ce qui est de strcat :

alors out_cat[14]=in_cat[14-14]

Faux tu as oublié un détail

Il faut aussi que tu écrases le caractère de fin de chaîne de out-cat (le fameux \0) qui se trouve à la fin de out_cat. Donc il faut que tu commence la copie à strlen(out_cat) - 1

oui sauf qu'à priori strlen compte ++ tant que valeur = vrai, et si en ascii '\0'= absence de valeur alors valeur=faux donc ce carractère ne doit pas etre compté, a priori

(en tout cas dans mon debug j'ai bien pour

C_tableau1[100]="c est la mere michelle"

C_tableau2[100]="qui a perdu sont char"

=>"c 'est la mere michellequi a perdu sont char")

alors que si j'ajoute -1 sa me vire le dernier e de michelle

marrant les quote spoiler, au debut g crus un bug

[GROS_FAIGNAN]

juste pour dire un grand merci a tous pour toute l'aide, Precieuse, que vous m'avez apportée.

et banzaï

[Shtong]

Expliqué autrement : un pointeur n'est qu'un numéro (généralement un entier (donc quatre octets), qui va désigner un emplacement dans la mémoire du programme), il a donc toujours la même taille ^^

d'accord mais je vois pas pourquoi strlen (prenant un long[tableau] (donc un const long *) en entré) me renverrait la taille en octet de mon pointeur ???

Ah ben non strlen devrait bien renvoyer le nombre de caractères oui (ça m'apprendra à ne pas lire les trucs dont je parle ) Je croyais que vous parliez de sizeof() ou un truc de ce genre

[Mephisto]

pour le principe:

strcmp:

quand le caractère est différent, tu return chaine1[x] - chaine2[x] (la différence des ASCII)

et oui, c'était long* dont je parlais (avec l'étoile en gras). car ça ne sert à rien de chercher une len si tu n'envois pas un pointeur (enfin, tu peux toujours t'amuser à n'envoyer qu'un élément, et te ballader dans ta mémoire jusqu'à trouver un élément t'indiquant la fin... mais dans ce cas de figure, bof...)

ps: theocrite, j'adore ta signature

[GROS_FAIGNAN]

strcmp:

quand le caractère est différent, tu return chaine1[x] - chaine2[x] (la différence des ASCII)

par contre je vient de retester strcmp (edition originale) avec 3 - 4 chaine différente et il ne me renvoie que 3 valeurs (-1,0 et 1) selon string1 par rapport a string2

alors que string1[x] - string2[x] j'ai du mal a comprendre ce qu'elle peut me retournée

par exemple : si string1="d......" (ascii=100)

et string2="P......" (ascii=80)

alors sa devrais me donné 100-80=20 => ascii (20)=DC4 (device control)

(ou alors peut etre que le calcul se fait pas comme sa ...)

en plus c'est censé me retourné un int, or d'après ce que tu ma expliqué ASCII, n'est valable que pour le type char...

et franchement j'ai essayer de trouver comment l'utiliser et je trouve pas (elle me retourne constament 0, sauf sur les chiffre ou elle fait bien le calcul).

donc, bah ....???

[BreizFenrir]

Si le strcmp original ne renvoie que -1, 0 ou 1, alors autant que ta réimplémentation le fasse aussi. Néanmoins la façon de faire de Mephisto n'est pas fausse, vu que la soustraction de valeur sans trop s'inquiéter de ce qui est retourné est quelque chose qui se fait souvent quand on écrit des fonctions de comparaison. Tout ce qui importe au final, c'est de savoir si la valeur retournée est négative, zéro ou positive ; ce qui indique la nature de la relation entre les chaînes ici.

Par contre il est une chose où tu te trompes : cette fonction ne retourne pas un caractère, ça n'a donc pas de sens dans ton exemple de dire que la valeur retournée est ASCII(20). C'est juste 20 ! Voire même c'est juste une valeur positive, vu que c'est tout ce qui importe. Après, que la valeur retournée soit de type char ou de type int, ça n'est pas important, vu que les deux types représentent leurs valeurs sous forme de nombres. Et puis la conversion de char vers int est normalement triviale (ce dernier type couvrant entièrement l'espace des valeurs autorisées avec char).

C'est avec quelle fonction que la comparaison ne fonctionne qu'avec les chiffres ? Ça me semble bizarre comme comportement.

[Mephisto]

un extrait du man:

RETURN VALUES

The strcmp() and strncmp() return an integer greater than, equal to, or

less than 0, according as the string s1 is greater than, equal to, or

less than the string s2. The comparison is done using unsigned charac-

ters, so that `\200' is greater than `\0'.

bon, c'est vrai c'est pas très explicite comme ça...

un exemple:

~# cat toto.c
int			 main(void)
{
char		*str1, *str2, *str3;

str1 = strdup("TEST 1");
str2 = strdup("TEST 2");
str3 = strdup("test 3");

printf("%s - %s -> %d (%d)\n", str1, str2, strcmp(str1, str2), strcmp(str2, str1));
printf("%s - %s -> %d (%d)\n", str2, str3, strcmp(str2, str3), strcmp(str3, str2));

return 0;
}
~# ./a.out
TEST 1 - TEST 2 -> -1 (1)
TEST 2 - test 3 -> -32 (32)

après, si l'implémentation sous winwin est différente, c'est de l'hérétisme. :)

[GROS_FAIGNAN]

implementation winwin

~# ./a.out
TEST 1 - TEST 2 -> -1 (1)
TEST 2 - test 3 -> -1(1)

après, si l'implémentation sous winwin est différente, c'est de l'hérétisme. :)

ho! grand mephistophélès, par pitié ne brule pas le pauvre faignan que je suis, prend bill gates a ma place.

après tout c'est bien connu, win diffuse des chant satanique si ont le fait tourner à l'envers (bdg.com^^).

et pour strchr quesque tu pense de sa:

char *str_search(const char *string1, char car)
{
long i=0;
for (i=0;string1[i]!=car;i++);
return &string1[i];
}

bien que ma fonction fonctionne, je l'ai testée sous différents codages et il me renvoie constament : "warning C4090: 'return' : qualificateurs 'const' différents"

=> d'ailleur c'est un peut bizarre de lire sa, c'est comme si je disait qu'une cigogne a les deux pattes pareilles, surtout la gauche...

pour str_comp j'ai finis par trouver sa :

int char_comp(const char *string1, const char *string2)
{
int i=0;
do
{
	i++;
}
while(string1[i]==string2[i]);
return string1[i]-string2[i];
}

ce qui si j'ai bien compris renvoie la différence de valeur du premier caractere string2 différent de string1 à la meme position i

C'est avec quelle fonction que la comparaison ne fonctionne qu'avec les chiffres ? Ça me semble bizarre comme comportement.

j'arrive pas à retrouver exatcement comment j'avais foutu mon truc mais je pense que c'est par ce que au lieu de faire

 return string1[i]-string2[i]

je faisait

long delta=0;
delta=string1[i]-string2[i];
return delta;

en tout cas depuis que je l'ai viré j'ai des resultats un peut plus cohérents.

[Mephisto]

après, si l'implémentation sous winwin est différente, c'est de l'hérétisme. :)

ho! grand mephistophélès, par pitié ne brule pas le pauvre faignan que je suis, prend bill gates a ma place.

après tout c'est bien connu, win diffuse des chant satanique si ont le fait tourner à l'envers (bdg.com^^).

OK, surprenant, mais je découvre la libC windows avec toi.

et pour strchr quesque tu pense de sa:

char *str_search(const char *string1, char car)
{
long i=0;
for (i=0;string1[i]!=car;i++);
return &string1[i];
}

bien que ma fonction fonctionne, je l'ai testée sous différents codages et il me renvoie constament : "warning C4090: 'return' : qualificateurs 'const' différents"

=> d'ailleur c'est un peut bizarre de lire sa, c'est comme si je disait qu'une cigogne a les deux pattes pareilles, surtout la gauche...

Le warning est normal.

Tu prends en paramètre un const char*, et tu retourne l'adresse d'un élément de ce paramètre. Tu renvois donc un const char*, et non un char*.

Tu dois donc soit changer le prototypage de ta fonction (const char* au lieu de char*), soit caster ce que tu retournes ( return (char*)(&string1); ). Sinon, pour le principe, c'est nikel.

pour str_comp j'ai finis par trouver sa :

int char_comp(const char *string1, const char *string2)
{
int i=0;
do
{
	i++;
}
while(string1[i]==string2[i]);
return string1[i]-string2[i];
}

En effet, ça ressemble plus à celui que je connais

(et désolé d'avoir insisté, j'ai toujours du mal à comprendre comment une fonction aussi bidon que strcmp puisse avoir deux comportements différents)

[Spaz001]

après, si l'implémentation sous winwin est différente, c'est de l'hérétisme. :)

ho! grand mephistophélès, par pitié ne brule pas le pauvre faignan que je suis, prend bill gates a ma place.

après tout c'est bien connu, win diffuse des chant satanique si ont le fait tourner à l'envers (bdg.com^^).

OK, surprenant, mais je découvre la libC windows avec toi.

et pour strchr quesque tu pense de sa:

char *str_search(const char *string1, char car)
{
long i=0;
for (i=0;string1[i]!=car;i++);
return &string1[i];
}

bien que ma fonction fonctionne, je l'ai testée sous différents codages et il me renvoie constament : "warning C4090: 'return' : qualificateurs 'const' différents"

=> d'ailleur c'est un peut bizarre de lire sa, c'est comme si je disait qu'une cigogne a les deux pattes pareilles, surtout la gauche...

Le warning est normal.

Tu prends en paramètre un const char*, et tu retourne l'adresse d'un élément de ce paramètre. Tu renvois donc un const char*, et non un char*.

Tu dois donc soit changer le prototypage de ta fonction (const char* au lieu de char*), soit caster ce que tu retournes ( return (char*)(&string1); ). Sinon, pour le principe, c'est nikel.

Une fonction search qui ne peut pas renvoyer 0, c'est bizarre ?

char * str_search(char * string1, char car)
{
long i=0;
for (i=0;string1[i] && string1[i]!=car;i++);
return (string1[i]==car) ? string1+i : 0;
}

Sur le même principe, str_comp est faux (non vérif de \0)

[Mephisto]

char * str_search(char * string1, char car)
{
long i=0;
for (i=0;string1[i] && string1[i]!=car;i++);
return (string1[i]==car) ? string1+i : 0;
}

Sur le même principe, str_comp est faux (non vérif de \0)

en effet, mea culpa

[Shtong]

après, si l'implémentation sous winwin est différente, c'est de l'hérétisme. :)

ho! grand mephistophélès, par pitié ne brule pas le pauvre faignan que je suis, prend bill gates a ma place.

après tout c'est bien connu, win diffuse des chant satanique si ont le fait tourner à l'envers (bdg.com^^).

OK, surprenant, mais je découvre la libC windows avec toi.

Bande de trolleurs strcmp fonctionne de la même manière sous windows que sous linux hein

Pour le str_comp, attention à la boucle do/while qui risque bien de ne pas prendre en compte le premier caractère !

[Mephisto]

~# ./a.out
TEST 1 - TEST 2 -> -1 (1)
TEST 2 - test 3 -> -1(1)

ça ressemble pas vraiment au strcmp que je connaisse. mais si faignan dit avoir repris mon bout de code pour obtenir ces resultats sous une winbox... mettez-vous d'accord une bonne fois pour toute ! ^^

[GROS_FAIGNAN]

~# ./a.out
TEST 1 - TEST 2 -> -1 (1)
TEST 2 - test 3 -> -1(1)

ça ressemble pas vraiment au strcmp que je connaisse. mais si faignan dit avoir repris mon bout de code pour obtenir ces resultats sous une winbox... mettez-vous d'accord une bonne fois pour toute ! ^^

pour mettre fin a l'attaque des troll je confirme que j'ai bien cette sortie de strcmp de mon coté (et j'ai fait un copié collé de ta fonction...) Nah!

ensuite, concernant strcrh j'ai fait deux test : 1 avec une recherche "vide" qui fonction et une autre avec une recherche d'un carractere n'existant pas dans la chaine et dans ce cas la effectivement , sa fouille dans la memoire jusqu'à temps d'en trouver un,

j'avoue que j'ai mis un peut de temps a comprendre mais après test c'est effectivement plus propre, merci pour le tuyau.

Sur le même principe, str_comp est faux (non vérif de \0)

donc j'ai refais le codage comme sa

int char_comp(const char *string1, const char *string2)
{
int i=0;
for(i=0;string1[i]&&string2[i]&&string1[i]==string2[i];i++);
return(string1[i]!=string2[i])? string1[i]-string2[i]:0;
}

mais forcement comme je peut pas comparé avec l'implementation win que j'ai, si ce n'est pour une valeur vide dans string1.

par ailleur a ce propos quand string2 est "vide" meme strcmp initiale me renvoie une valeur positive

par contre d'un point de vue pratique a quoi peut bien servir de connaitre la différence algebrique de 2 caractère si la fonction ne renvoie pas la position de ces caractère dans les chaine correspondante . (et meme d'un point de vue plus générale... a quoi sa peut servir).

(et désolé d'avoir insisté, j'ai toujours du mal à comprendre comment une fonction aussi bidon que strcmp puisse avoir deux comportements différents)

qui aime bien - chat ti bien (vous défoulez pas sur moi non plus hein !!!)

dis autrement : c'est en pinaillant qu'on apprend

concernant strlen codé comme sa

long nouveau(const char* str)
{
long n;

for (n = 0; str[n]; n++);

return n;
}

y doit y avoir une petite différence avec strlen, car lorsque j'utilise strlen il me renvoie constament un "warning C4018: '<' : incompatibilité signed/unsigned"

et pas avec la version "nouveau" ^^, ce qui m'arrange d'ailleur. par contre je ne sais pas à quoi c'est du...

Pour le str_comp, attention à la boucle do/while qui risque bien de ne pas prendre en compte le premier caractère !

ok, effectivement avec une while simple sa passe mieux.

et pour deborder un peut j'ai commencer a test le préprocesseur, les ouverture et ecriture dans fichier, et ...MALLOC

de loin, comme sa, sa à l'air sympa et pratique mais en vrai c'est que sa mord ces bettes la.

et franchement pour s'y retrouver dans un code de ne serait ce que 200 lignes sa commence a devenir gallère.

[Spaz001]

Sur le même principe, str_comp est faux (non vérif de \0)

donc j'ai refais le codage comme sa

int char_comp(const char *string1, const char *string2)
{
int i=0;
for(i=0;string1[i]&&string2[i]&&string1[i]==string2[i];i++);
return(string1[i]!=string2[i])? string1[i]-string2[i]:0;
}

mais forcement comme je peut pas comparé avec l'implementation win que j'ai, si ce n'est pour une valeur vide dans string1.

par ailleur a ce propos quand string2 est "vide" meme strcmp initiale me renvoie une valeur positive

par contre d'un point de vue pratique a quoi peut bien servir de connaitre la différence algebrique de 2 caractère si la fonction ne renvoie pas la position de ces caractère dans les chaine correspondante . (et meme d'un point de vue plus générale... a quoi sa peut servir).

Tout simplement à trier des chaînes de caractères.

"AB" < "AC" < "B" < "CA"

(et désolé d'avoir insisté, j'ai toujours du mal à comprendre comment une fonction aussi bidon que strcmp puisse avoir deux comportements différents)

qui aime bien - chat ti bien (vous défoulez pas sur moi non plus hein !!!)

dis autrement : c'est en pinaillant qu'on apprend

concernant strlen codé comme sa

long nouveau(const char* str)
{
long n;

for (n = 0; str[n]; n++);

return n;
}

y doit y avoir une petite différence avec strlen, car lorsque j'utilise strlen il me renvoie constament un "warning C4018: '<' : incompatibilité signed/unsigned"

et pas avec la version "nouveau" ^^, ce qui m'arrange d'ailleur. par contre je ne sais pas à quoi c'est du...

Alors je vais dire un truc qui parait logique, la longueur d'une chaîne est forcément >= 0. Donc le type retourné est unsigned.

[Mephisto]

+1 pour le unsigned

en remontant dans les premiers messages, j'avais donné un exemple en size_t - passé à la trappe ^^

[GROS_FAIGNAN]

+1 pour le unsigned

en remontant dans les premiers messages, j'avais donné un exemple en size_t - passé à la trappe ^^

effectivement, dsl.

bon sinon j'en ai encore une petite dernière, et je vais tacher d'etre (plus) attentif cette fois.

en gros je voulais savoir si il etait possible de creer un pointeur sur une variable stocké dans un fichier. j'ai quelque part l'impression de poser un question un peut bete puisque un fichier (par exemple .txt) ne stocke pas les variables mais seulement leur valeur.

en gros mon probleme c'est que je veut determiné par exemple une valeur associés a une chaine de caractère (genre 1 espace plus loin) jusque la sa va et lui dire

if (ma chaine dans le programme == ma chaine dans fichier)

alors(pointeur t'es prié de modifier comme sa (ma fonction de modif) les valeurs suivantes)

je suis partie de ce principe la pour lui faire démarrer ma boucle de lecture (scoring est le nom de mon fichier)

	if(scoring!=NULL)
{
	rewind(scoring);
	if(fgetc(scoring)!=E0F);
	{
		rewind(scoring);
		while(fscanf(scoring,"%s %d %d",x_joueur.nom,x_joueur.moyenne,x_joueur.partie)!=EOF)
		{
			if(x_joueur.nom==joueur.nom)

abstractivement sa devrait fonctionner mais j'ai pas pu faire de test en grandeur réelle par ce que, j'arrive pas a ecrire la suite.

bon j'avoue c'est peut etre encore un peut compliqué

j'ai bien tenté un truc du genre

fopen("scoring.xls","r+")

histoire de me donner un look de barbare mais forcement maintenant je vois pas comment faire appel aux fonctions de excell....

meme si l'enregistrement de mes valeur se fait dans les bonnes "cases".

donc comme disait mon pere, maintenant je l'ai dans le c*l la balayette.

( ... ont dirait pas mais sa fait quand meme vachement mal une balayette!)

[Mephisto]

Lorsque tu ouvres un fichier, tu obtiens un file descriptor (grosso merdo).

Il te permet de lire le contenu du fichier, et se comporte comme un "tête de lecture": le fd ne te permet de lire qu'à un seul endroit du fichier, de manière linéaire. Et pour te déplacer dans le texte sans le lire, tu as lseek().

Tout ça pour dire que, sans bufferisation de ton fichier, tu ne pourra pas accéder "instantanément" à son contenu.

Mais ton bout de code devrait faire l'affaire. Il faut par contre faire attention de ne pas tomber sur un fichier daubé, ça baiser**t ta mécanique

Par contre, scoring.xls....

Tu vas avoir des soucis, entre ce qu'excel t'affiche, et ce que le fichier contient vraiment, il y a une grosse différence.

Pour le trip, recode hexdump et regarde ce que ton fichier contient ^^

[GROS_FAIGNAN]

Lorsque tu ouvres un fichier, tu obtiens un file descriptor (grosso merdo).

Il te permet de lire le contenu du fichier, et se comporte comme un "tête de lecture": le fd ne te permet de lire qu'à un seul endroit du fichier, de manière linéaire. Et pour te déplacer dans le texte sans le lire, tu as lseek().

Tout ça pour dire que, sans bufferisation de ton fichier, tu ne pourra pas accéder "instantanément" à son contenu.

Mais ton bout de code devrait faire l'affaire. Il faut par contre faire attention de ne pas tomber sur un fichier daubé, ça baiser**t ta mécanique

là j'avour que pour le coup tu me donne des fil a detordre.... (mais après tout faut bien que je bosse un peut)

juste pour me mettre sur la voie, si j'ai bien capté, mon pointeur FILE* pointe pas vraiement sur mon "file.txt" mais sur le file descriptor qui vas, lui, lire les caractère un par un....?

pour les question de buffer je planche encore.... :smiley_bucheron:

Par contre, scoring.xls....

Tu vas avoir des soucis, entre ce qu'excel t'affiche, et ce que le fichier contient vraiment, il y a une grosse différence.

Pour le trip, recode hexdump et regarde ce que ton fichier contient ^^

lib <c.dur> was linked

read in progress ......0100010101101101....

: error 2.much: dont locate comprehensible define of "file descriptor" in wiki database

: error C2065 : 'hexdump' : identifier not define for windows

dont find wiki explains, googles are unintelligible

language unsupported, brain overflow, stderr=("....you are the ugly duckling...please retry later.... goodbye")

...mais comme je l'ai dit je planche encore

[Mephisto]

"pour les questions de buffer", c'est pas compliqué.

puisque le file descriptor ne te permet pas d'accéder instantanément à n'importe quel élément de ton fichier, tu dois trouver un moyen de 'bufferiser' le fichier.

enfin, ça a ses limites: si le fichier est trop volumineux, tu peux rapidement te trouver avec une RAM saturé.

mais pour en arriver là, ton fichier doit faire plusieurs centaines de mégas.

donc, si le fichier n'est pas "trop volumineux", un simple, tu peux te contenter de lire son contenu, et de le copier dans un buffer.

à chaque occurence, tu realloc ton buffer (ou tu trouve une technique plus propre), et tu le complète avec ce que tu as lu.

rapidement (c'est moche, pas testé, ...), ça pourrait donner:

#define BUF_SIZE 420
char		  *getfile(int file_descriptor)
{
int		 x;
char	  buf[BUF_SIZE + 1], *tmp, *file = NULL;

tmp = strdup("");
while ((x = read(file_descriptor, &buf, BUF_SIZE)))
{
	buf[x] = 0;
	if (file) { tmp = strdup(file); free(file); }
	asprintf(&file, "%s%s", tmp, buf);
	free(tmp);
}

return buf;
}

et pour ce qui est des .xls:

le contenu d'un fichier peut être du texte, ou bien une représentation de celui-ci (et par extention, une représentation d'une image / un film / ...)

après, faut t'adresser à quelqu'un d'autre si tu veux comprendre la structure d'un fichier excel, mais dans le principe, le contenu d'un fichier .xls est "modélisé".

C'est comme si, à la sauvegarde dans un fichier, excel réécrivait le contenu sous la forme "ligne1:colonne1:data1"

sauf que c'est pas modélisé comme ça, et que ça pourrait tout aussi bien être "\0\0\1\0\0\0\2\1\1\0\1\0\2\1\0\0\1"

dans ce genre de cas: direction les docs sur le format de fichier, les éventuelles libs consacrées, ...

[GROS_FAIGNAN]

donc, si le fichier n'est pas "trop volumineux", un simple, tu peux te contenter de lire son contenu, et de le copier dans un buffer.

à chaque occurence, tu realloc ton buffer (ou tu trouve une technique plus propre), et tu le complète avec ce que tu as lu.

d'accord mais si je suis bien ce qui a été vu avant sur les poitneur, ce que je met dans le buffer ne serat qu'une "copie" de mon fichier et pas le fichier en lui meme ...non?

donc tenter un truc du genre buffer une copie du fichier, travailler dessus, et stocker le resultat en memoire, ferme mon fichier, le réouvrir en mode W+ pour qu'il efface tout puis faire une copie de ma memoire dans le fichier vide me semble peut etre théoriquement possible (et encore) mais vachement bancale.

d'un autre coté j'ai pas envie de tout planter!!

pour ce qui est de la bufferisation j'ai vue un truc "setvbuf" avec le man a cette adresse mais c'est pas facile d'acces

pour les xls, pour l'instant je mets de coté, inabordable

sinon, je me trompe surement mais

tmp=strdup("")

est ce que sa revient pas au meme que

*tmp=NULL

parce que dans le premier cas le pointeur tmp pointe sur l'adresse d'une copie de ...rien (ou vide)

et dans l'autre cas valeur de pointeur tmp=vide

[Mephisto]

d'accord mais si je suis bien ce qui a été vu avant sur les poitneur, ce que je met dans le buffer ne serat qu'une "copie" de mon fichier et pas le fichier en lui meme ...non?

exact

donc tenter un truc du genre buffer une copie du fichier, travailler dessus, et stocker le resultat en memoire, ferme mon fichier, le réouvrir en mode W+ pour qu'il efface tout puis faire une copie de ma memoire dans le fichier vide me semble peut etre théoriquement possible (et encore) mais vachement bancale.

bancale, c'est un apriori ^^

c'est la manière générale de procéder.

sinon, je me trompe surement mais

tmp=strdup("")

est ce que sa revient pas au meme que

*tmp=NULL

parce que dans le premier cas le pointeur tmp pointe sur l'adresse d'une copie de ...rien (ou vide)

et dans l'autre cas valeur de pointeur tmp=vide

non

la différence est qu'avec un strdup de "", tu crées (donc, tu alloue) un pointeur vers la chaine "\0"

donc tu peux l'envoyer à free() sans avoir de message d'erreur (essais de free quelque chose qui n'est pas malloc)

par contre, si tu le fais en C++, tu as beaucoup plus simple que setvbuf

bon, les puristes prétendront le contraire, mais sans chercher à connaître toutes les fonctions de la lib, tu peux te simplifier la tâche en utilisant certaines "fonctionnalitées" des objets que tu utilise déjà.

si tu veux vraiment te lancer dans le cpp maintenant, intéresse-toi d'abord aux surcharges d'opérateurs.

tu as l'objet string (qui ne viendra plus t'emmerder avec les considérations existentielles sur ta gestion mémoire)

tu as les objets de stream (à toi de lire la doc et de choisir le bon ^^)

et tu as les opérateurs <<, >>, +=, ..... qui sont souvent implémentées pour les 'objets récurrents'

continues de parcourir cplusplus.com, t'es tombé sur le bon site.

par contre, c'est beaucoup plus flexible et complet que le C. tu vas passer plus de temps à lire les docs.

courage

[GROS_FAIGNAN]

non

la différence est qu'avec un strdup de "", tu crées (donc, tu alloue) un pointeur vers la chaine "\0"

donc tu peux l'envoyer à free() sans avoir de message d'erreur (essais de free quelque chose qui n'est pas malloc)

Ok je croit que j'ai pigé

en gros sa revient au meme que

char *ptr;
char tableau[]="";
*ptr=tableau[] (ou *tableau)

sauf que sa evite d'avoir besoin de creer une variable vide a chaque fois qu'on en a besoins puisque cette dernière est créée dans strdup. ??

par contre tu me disait d'eviter les tableau, et vue que je commence a bosser malloc, j'ai chercher voire comment stocké un string dans autre chose et, bah c'est pas expliqué.

j'ai bien tester 2-3 truc sans y croire vraiment, et sa c'est reveler sans interet.

par contre, si tu le fais en C++, tu as beaucoup plus simple que setvbuf

bon, les puristes prétendront le contraire, mais sans chercher à connaître toutes les fonctions de la lib, tu peux te simplifier la tâche en utilisant certaines "fonctionnalitées" des objets que tu utilise déjà.

si tu veux vraiment te lancer dans le cpp maintenant, intéresse-toi d'abord aux surcharges d'opérateurs.

tu as l'objet string (qui ne viendra plus t'emmerder avec les considérations existentielles sur ta gestion mémoire)

tu as les objets de stream (à toi de lire la doc et de choisir le bon ^^)

et tu as les opérateurs <<, >>, +=, ..... qui sont souvent implémentées pour les 'objets récurrents'

continues de parcourir cplusplus.com, t'es tombé sur le bon site.

par contre, c'est beaucoup plus flexible et complet que le C. tu vas passer plus de temps à lire les docs.

courage

c'est noté.

le C++ c'est prevu mais pas tout de suite, je prefere d'abord bien maitriser le C avant de me lancer, histoire de faire les chose dans l'ordre. (j'espere d'ici 5-6 mois mais je m'avance pas non plus, ont sais jamais).

[Spaz001]

non

la différence est qu'avec un strdup de "", tu crées (donc, tu alloue) un pointeur vers la chaine "\0"

donc tu peux l'envoyer à free() sans avoir de message d'erreur (essais de free quelque chose qui n'est pas malloc)

Ok je croit que j'ai pigé

en gros sa revient au meme que

char *ptr;
char tableau[]="";
*ptr=tableau[] (ou *tableau)

sauf que sa evite d'avoir besoin de creer une variable vide a chaque fois qu'on en a besoins puisque cette dernière est créée dans strdup. ??

Je ne connais pas strdup mais je ne pense pas que ce soit exactement ça non plus.

Là, tu fais pointer (si tu avais écrit correctement '^^) ptr sur la chaine statique "".

Cette chaîne là n'est pas alloué dynamiquement, et n'est pas libérable (pas de free dessus).

strdup serait plus un truc genre

char * strdup(const char * const dup)
{
char * ret = malloc(strlen(dup)*sizeof(char));
strcpy(ret,dup);
return ret;
}

Mephisto infirmera ou confirmera

[GROS_FAIGNAN]

Je ne connais pas strdup mais je ne pense pas que ce soit exactement ça non plus.

Là, tu fais pointer (si tu avais écrit correctement '^^) ptr sur la chaine statique "".

Cette chaîne là n'est pas alloué dynamiquement, et n'est pas libérable (pas de free dessus).

char *ptr;
char tableau[]="";
*ptr=tableau

effectivement sa doit etre mieux comme sa puisque pointeur doit contenir l'adresse.

strdup serait plus un truc genre

char * strdup(const char * const dup)
{
char * ret = malloc(strlen(dup)*sizeof(char));
strcpy(ret,dup);
return ret;
}

Mephisto infirmera ou confirmera

effectivement sa revient a ce que disait mephisto plus haut sur le fait de free un non-malloc

par contre la si je suit ton raisonnement sur strdup enfait tu malloc autant de char à *ret qu'il y a d'element de string passé en entrée (a dup)

donc est ce que sa revient a creer un type qui fait X*char ou alors une quantité X d'element faisant chacun char (ce qui revient au meme qu'un tableau ...)?

je sais pas si c'est très clair

dit autrement si char =1octet, et que X=strlen(dup) alors

malloc correspond à X element de 1 octet (eventuellement alloué consécutivement en memoire) soit comme pour un tableau

ou alors à 1 element de X*1octet ?