Float Datentyp byteweise aufsplitten

[Thorsten80]

Hallo

Also ich habe folgendes Problem. Ich habe eine Programm geschrieben, das übers Netzwerk Daten verschickt. Nun möchte ich dieser Send eine Gleitkommazahl mitschicken. Ich kann aber nur byte buffer[1024] oder so ähnlich als Argument übergeben. Also ich möchte die 4 bytes in denen die float-Zahl drinsteht in 4 verschiedene bytes oder chars aufteilen. Das ganze hab ich schon mit ints usw gemacht, auch string und das ging ganz einfach. NUr bei dem float kann ich nicht & oder | verknüpfen um die bytes zu isolieren un dich kann auch nicht schifften mit >> oder << wie bei den anderen Datentypen. Ich habs auch mit casts probiert. Der reinterpret_cast dachte ich würde gehen aber dabei bekomm ich immer nur ne fehlermeldung.

Hat da jemand ne idee wie das gehen könnte? ich brauchs dann auch umgekehrt, muss also aus 4 empfangenen bytes wieder die float Zahl zurückgewinnen können.

[CStoll]

auch wenn's etwas radikal ist, versuch' es mal mit einer union

[Thorsten80]

Kannst Du das vielleicht etwas genauer erklären? Ich steh etwas auf dem Schlauch.

also wenn ich folgendes hab.

byte* buffer[4];
float zahl = -5.2;

Wie bekomm ich dann die Hexdarstellung von zahl in buffer[0] bis buffer[3] ?

[Pellaeon]

union myFloat
{
   byte* buffer[4];
   float zahl;
};

Das meint er. Die beiden teilen sich jetzt einen Speicherbereich. Wenn du float beschreibst, kannst du über deinen buffer die bytes auslesen

[CStoll]

union f2b
{
  char chrs[sizeof(float)];
  float val;
} convert;

// zahl -> buffer
convert.val=zahl;
memcpy(buffer,convert.chrs,sizeof(float));

// buffer -> zahl
memcpy(convert.chrs,buffer,sizeof(float));
zahl=convert.val;

(aber ich bin sicher, da gibt es elegantere Lösungen)

[7H3 N4C3R]

Der Standard erlaubt das nicht (9.5 Clause 1).

[Thorsten80]

Ich hab das jetzt mit der union gemacht und es funktioniert. DANKE für die Hilfe, wär ich von allein nie drauf gekommen !!!

[???????????]

es wurde doch gesagt das das nicht erlaubt ist und du machst es trotzdem?

[camper]

7H3 N4C3R schrieb:

Der Standard erlaubt das nicht (9.5 Clause 1).

unsinn. lies das mal richtig. dort steht nur, was den fundamentalen unterschied zwischen union und struct ausmacht, nähmlich, dass man nicht daten in von verschiedenen membern gleichzeitig darin speichern kann. nur der zuletzt gespeicherte wert ist garantiert enthalten, das ist was mit aktiv gemeint ist. keineswegs steht das der möglichkeit entgegen, unions zum casten zu benutzen. der standard garantiert nat. keine bestimmten werte, denn diese form des castens hängt stets von der implementation ab - ein zerlegen von PODs in (unsigned) char arrays ist immer legal. im übrigen sei noch auf 3.9 clause 2 verwiesen.

[7H3 N4C3R]

camper schrieb:

7H3 N4C3R schrieb:

Der Standard erlaubt das nicht (9.5 Clause 1).

unsinn. lies das mal richtig. dort steht nur, was den fundamentalen unterschied zwischen union und struct ausmacht, nähmlich, dass man nicht daten in von verschiedenen membern gleichzeitig darin speichern kann. nur der zuletzt gespeicherte wert ist garantiert enthalten, das ist was mit aktiv gemeint ist. keineswegs steht das der möglichkeit entgegen, unions zum casten zu benutzen. der standard garantiert nat. keine bestimmten werte, denn diese form des castens hängt stets von der implementation ab - ein zerlegen von PODs in (unsigned) char arrays ist immer legal. im übrigen sei noch auf 3.9 clause 2 verwiesen.

In a union, at most one of the data members can be active at any time, that is, the value of at most one of the data members can be stored in a union at any time. [Note: one special guarantee is made in order to simplify the use of unions: If a PODunion contains several PODstructs that share a common initial sequence (9.2), and if an object of this PODunion type contains one of the PODstructs, it is permitted to inspect the common initial sequence of any of PODstruct members;
(was impliziert, dass alles andere nicht erlaubt ist)

Du hast es aber auch sehr schön selbst formuliert, dass es nicht erlaubt ist. Nur der Zugriff auf das zuletzt zugewiesene Element ist gestattet. Da "erlaubt" kein vom Standard sanktioniertes Wort ist - es ist undefiniert. Da steht auch kein Wort von implementation defined.

In Hinsicht auf 3.9 hast Du aber recht. Wobei dabei wiederum keine Union verwendet werden sollte, sondern wie auch im Standard gezeigt memcpy (Zitat: the underlying bytes can be copied ...).

keineswegs steht das der mglichkeit entgegen, unions zum casten zu benutzen.

Ist das so? Definierte Standard-Conversions werden umgangen. Union-casten ist sogar noch schlimmer als ein reinterpret oder C-Style cast.

Noch was:
Wenn Du's hast: Lies C++ Coding Standards (Sutter, Alexandrescu), Item 97.

[HumeSikkins]

@Thorsten80
Wie sieht die genaue Signatur der send-Funktion aus? Normalerweise sollte eine generische send-Funktion als Parameter einen (unsigned) char-Type erwarten (Referenz oder Pointer), da du laut Standard jedes Objekt über (unsigned) char ansprechen kannst.

Angenommen deine send-Funktion hat die Signatur:

int send (
  SOCKET s,              
  const char* buf,  
  int len
);

dann kannst du einen float f z.B. so senden:

SOCKET s = ...;
float f = 2.0f;
send(s, reinterpret_cast<const char*>(&f), sizeof(f));

Besonders sinnvoll ist das aber nicht, da dir niemand garantiert, dass überall im Netz die selbe float-Repräsentation verwendet wird. Sprich, wenn du auf der anderen Seite die Bytes in einen float zurückwandelst muss da noch lange nicht der selbe Wert rauskommen.

Besser wäre es da schon den float vorher in ein Standard-Format zu konvertieren (z.B. IEEE-Kodierung, XDR oder gar einen String).

[ieee-fetischist]

Ist float nicht in IEEE-Kodierung??

[Standarte]

ieee-fetischist schrieb:

Ist float nicht in IEEE-Kodierung??

Ist nicht vom Standard festgelegt, also implementationsspezifisch AFAIK.