je me demandais s´il était possible d´enregistrer l´adresse d´un pointeur vers un autre d´unautre type.

exemple :

j´ai un tableau d´octet.
j´aimerais sauvegardé sur 4 octet depuis disont l´octet 10 jusqu´à l´octet 13 un long

alors bien sur on peut manipuler les bit, mais c´est pas terrible.

mais mon compilo fait une erreur sur un truc du genre :
long *Ptr;
long *Ptr2
char Var[20];
Ptr=&[10]

• Ptr=123456;

le compilo n´accepte pas la dernière ligne en me disant que l´operand de gauche à le type char ( bizarre), mais juste avant j´avais un programme très légerement différend où il palntais à la ligne précédente.

Y a t il une manière de faire ça sans utiliser des memcpy ( je ne sais pas si c´est ça qu´il faudrait utiliser) ou autre fonction de la bibliothèque standard, mais juste en utilisant les éléments du langage ?
merci d´avance pour vos réponse.

merci j´ai trouvé, suffisait de caster les pointeur ( c´est con, mais j´y avais pas pensé).

Salut semaj tu peux me dire à quoi ça te sert de sauvegarder sur tels octets ? J´arrive pas encore à bien capter l´utilité du truc.

je comprend pas trop ta question mais je vais t´expliquer pour quoi j´en ai besoin :

en gros, je crée un programme qui exécute des instruction contenu sous forme d´OpCode dans un tableau d´octet.

Mais parfois il faut utiliser des chiffres et comme je ne voulais pas me limité aux char, il me fallait un moyen de stocker et de lire des long en l´occurence ( mais ça pourrait être des float ou des double) dans mon tableau d´octet.

Avec cette méthode c´est facile et pratique.

Sinon il faut jongler avec les ET, les OU, les < < et les > >

Tu as bien compris

C´est tout de même plus rapide avec des opérateurs bit à bit ( :

comment on maipule les bits?

jarose, tu pense que c´est plus rapide avec des opérateur bit à bit ?

voila comment ej le faisait avant ( il y a peut-être plus simple, mais difficlement plus simple que la méthode du dessus) :

File[FilePos++]=(unsigned char)(Param & 0xFF000000L) > > 24;
File[FilePos++]=(unsigned char)((Param < < 8) & 0xFF000000L) > > 24;
File[FilePos++]=(unsigned char)((Param < < 16) & 0xFF000000L) > > 24;
File[FilePos++]=(unsigned char)((Param < < 24) & 0xFF000000L) > > 24;

dans un sens, et :
TempRead=File[Pos];
TempRead=(TempRead < < 8) | ( long)File[++Pos];
TempRead=(TempRead < < 8) | ( long)File[++Pos];
TempRead=(TempRead < < 8) | ( long)File[++Pos];
dans l´autre sens.

Mais bon, comment le ferais tu ?

tu peux économiser des < < dans le premier en décalant d´abord > > puis en masquant 0xFF ; mais ça reste plus lent qu´un cast ; le cast de pointeur va modifier l´adressage, point. En y allant à la main au mieux tu fais plusieurs acces en adressage basé et indexé, et au pire tu stalles le pipe V . .. cool... De plus le cast est portable LE/BE ( perso je m´en fous, mais c´est pour ceux qui mette ça en avant...)

protable LE/BE ?

je suis sur que c´est un truc trop cool, mais c´est quoi ?

Je disais: plus rapide en temp d´execution, pas en therme de codage.

En fait j´avais pas bien examiné et compris ton post. Mais maintenant je me demande:

Pourquoi faire ton tableau d´instructions avec des char ?
Et pourquoi utiliser des long avec ces instructions ?

-> J´en pense que c´est pas très optimisé si tu veux faire une vm, mais si t´es sûr que procéder de cette façon est plus adéquat, retires ce que j´ai dit.
Dans ton cas, caster dès le départ pour piocher directement dans la chaine, c´est plus rapide sur tout point.

je n´ai pas fait bcp d´étude sur la question, mais comme je n´ai pas énromément d´instruction, des char sont emplement suffisant, donc je pense que ça sert à rien de gacher de la mémoire ( c´est vrai qu´utiliser 4Ko au lieu de 1 ça semble rien, mais quand même). Par contre pour faire des calcul, des char c´est vraiment trop peu.

Donc les long me semble plus aproprié ( en attendant que je lui implémente une bibliothèque de calcul en précision infini qui est le but final de ma VM)

dnoob: LE/BE : little endian, big endian

lgv: muf muf muf, je tiens a preciser que ca depends comment tu fais ton cast:

int a[1];
char *b = ( char*) &

a[ 0 ] = 0x12345678;
printf( " %x\n", *b ) ;

/ / 68 pour LE et 12 pour BE..

kUfa : ah oui, je me suis mal exprimé, ce n´est pas ce que je voulais dire. Si tu colles tes données à la main avec décalage, tu assures l´ordre que tu veux, alors que si justement tu castes, l´arrangement mémoire va dépendre de LE ou BE : donc tu restes consistant et cohérent vis-à-vis du systeme en vigueur ; c´est ça que je voulais préciser. En LE tes données seront LE, en BE elles seront BE ; si tu fais ta tambouille à la main, ben... faut bien lire la recette pour pas se tromper ; )

pour ce qui est de la rapidité, un cast ( de pointeurs...) se traduit au niveau du code ASM généré par un simple changement de mode d´adressage, soit à coup de BYTE/WORD/DWORD PTR en spécification de l´opérande, soit à coup d´adressage basé + indexe explicite ; ce qui ne consomme donc RIEN en terme CPU, si ce n´est éventuellement un alignement. Donc je vois mal comment en faisant de SHL à la main tu peux concurrencer ça.
Exemple bidon qui cumule les deux :

int array[1];

• (reinterpret_cast<char *>(array) + 1) = 1;

devient betement :
mov byte ptr [ebp-7],1

Au mieux comme je disais, à coup de SHL consécutifs sur une meme opérande, tu bloques le parallelisme U/V ; donc soit t´intercales tes instructions, et là faut y´a aller en ASM pour etre sur du résultat, soit tu complexifies un peu le code... Mais je vois pas du tout où on peut gagner :-?

Je suis tout a fait d accord avec toi que le cast va donner le code le plus rapide ( quoi que sur amiga parfois tu peux avoir des gros cache misses lorsque l indexage est trop grand), mais, juste pour verifier qu on est d accord:

int array[1];
*(reinterpret_cast<char *>(array) + 1) = 1;

Non portable BE/LE mais version la plus rapide

oui, on est d´accord ( dans la mesure ou justement la on indexe a la main, on peut pas compter sur la " remise en ordre" LE/BE . .. de toute facon j´avais bien dit que ca servait a rien... LOL)

au passage, pareil en x86, si tu offset plus qu´un far jump, la modif d´adressage ne suffit pas

c est donc bien ce que je pensais, comme d hab on dit les meme choses