recupérer les 4 octets d'un reel 32bits

[invite5905bb4b]

Bonjour

afin de transmettre à une carte électronique un paramètre reel32bit, j'ai besoin de connaitre les 4 octets qui composent ce réel.

Sauriez vous me dire par quel outil je peux passer pour faire cela ? ( en delphi svp )

Merci par avance
-----

[Jack]

En C on fait ça avex des pointeurs. Je suppose qu'en PASCAL ça doit être la même chose.
Il faut dans tous les cas se préoccuper du boutisme du réel à transmettre car on n'est pas certain de la manière dont il sera stocké en mémoire.

[jiherve]

Bonsoir,
tu déclares un type union : un reel et 4 octets et hop!
Je te laisse chercher comment faire c'est formateur, tu as toutes le billes .
JR

[polo974]

google (delphi union)

yapuka...

[A voir en vidéo sur Futura]

[Bluedeep]

En C on fait ça avex des pointeurs. .

Aucune raison d'utiliser des pointeurs pour faire de l'introspection d'une structure de 4 octets (et un réel 32 bits n'est rien d'autre).

La bonne réponse est celle de jiherve : utiliser l'union (en C & C++), le record "case" (en Pascal), ou la class avec attribut StructLayout et FieldOffset (en C#).

[Jack]

Aucune raison d'utiliser des pointeurs pour faire de l'introspection d'une structure de 4 octets (et un réel 32 bits n'est rien d'autre).

C'est pourtant une possibilité.

La bonne réponse est celle de jiherve : utiliser l'union (en C & C++)

C'est effectivement la solution la plus élégante.

[inviteb9f49292]

Pour utiliser l'union, le pointeur ou des masques, il faut être sûr que les deux plateformes utilisent la même représentation... Sinon il faut utiliser une représentation "descritpive": communiquer la mantisse et l'exposant explicitement, où le format "%a" de printf / scanf (C99) s'il est supporté sur les deux plateformes

[Bluedeep]

Pour utiliser l'union, le pointeur ou des masques, il faut être sûr que les deux plateformes utilisent la même représentation... Sinon il faut utiliser une représentation "descritpive": communiquer la mantisse et l'exposant explicitement, où le format "%a" de printf / scanf (C99) s'il est supporté sur les deux plateformes

Sauf erreur de ma part, La représentation du float est normalisé IEEE 754 depuis 1985.

[bisou10]

tu as bien des manières de faire, mais un masque, un cast et un décalage me semble la plus adaptée. Restons cohérent, OP pose une question de base, choisissons une solution simple !

[Bluedeep]

tu as bien des manières de faire, mais un masque, un cast!

La solution simple c'est l'union (comme dit depuis le début); un cast ici ne marche pas.

[Jack]

La solution simple c'est l'union (comme dit depuis le début);

On est d'accord

un cast ici ne marche pas.

si, ça marche. En supposant que je compile sur une machine little endian

	float val = 0.5;
	unsigned char tab[4];
	unsigned char* p=(unsigned char*)&val;
	for (int i=3; i>=0; i--)
	{
		tab[i] = (unsigned char) *(p++);
	}

[Bluedeep]

On est d'accord
si, ça marche.

Quand je disait un cast ne marche pas, ça supposait bien évidemment "juste un cast"; ce qui n'est pas le cas dans l'exemple que tu donnes. (en C du moins; car en C++, il existe d'autres options, avec le dynamic_cast, etc ... et en C#, la possibilité de redéfinir l'opérateur de cast explicite et implicite permet aussi de faire ce qu'on veut ou presque avec un cast).

[Jack]

On est d'accord.

[inviteb9f49292]

Sauf erreur de ma part, La représentation du float est normalisé IEEE 754 depuis 1985.

Il n'y a pas d'erreur, c'est bien un standard d'une trentaine d'année, mais ce n'est pas pour autant que c'est le seul, ni que toutes les plateformes ne respecte ce standard précis... ce qui est d'autant plus vrai que dans l'embarqué il n'y a pas forcément de FPU... Il est vrai que les non-conformance à IEEE-754 que j'ai croisé était plus sur des aspects "mécaniques" (absence de symbole NAN, exceptions qui ne petent pas forcement au même conditions, arrondis gérés différement...) que sur la représentation, mais ça me semblait important à préciser car c'est tout de même la question fondamentale à se poser même si la réponse est oui à 99%.