ich bin mir nicht ganz sicher ob das hier richtig ist.

float Data=12.3;
unsigned char* bytes = reinterpret_cast<unsigned char*>(&Data);

ich will aus einer float zahl einen 4 byte charfeld machen.

ich bin mir nicht ganz sicher ob ich jetzt mit bytes in einen unbestimmten bereich schreibe, oder ob über das reinterpret_cast ein speicherbereich zugeordnet wird.

Danke schonmal

Das ganze ist um can-bus daten zu senden. dafür muss ich den float wert in unsigned char haben.

Was für eine Plattform ist denn der Datenempfänger?

ich bin mir nicht ganz sicher ob ich jetzt mit bytes in einen unbestimmten bereich schreibe, oder ob über das reinterpret_cast ein speicherbereich zugeordnet wird.

Stimmt schon, du greifst auf den Bereich des floats zu. Wie groß das float ist, kannst du ja mit sizeof rausfinden, bzw mit assert( sizeof(float) == X ) sicherstellen, dass es so groß ist, wie du annimmst. Hast Zugriff auf bytes[0] bis inklusive bytes[sizeof(float)-1] .
Auf Inkompatibilitäten der float-Darstellungen zielt Tachyon ja schon ab.

Als Programierumgebung nutze ich Borland c++. Aber das ist ja unabhängig von der Entwicklungsumgebung.

sizeof(float) ist 4. soviel ich weiß ist das doch genormt, oder?

ich hab heraus gefunden das ich die daten genau so auf diese art umwandeln kann.

float test=12.5;
unsigned char wert[4];

memcpy(wert,&test,4);

was jetzt schöner ist, ist mal dahingestellt.

sizeof(float) ist 4. soviel ich weiß ist das doch genormt, oder?

Absolut nicht. Wir haben hier DSPs, da ist sizeof(float) 1. Und das ist völlig Standardkonform. Bei solchen Sachen musst Du aufpassen. Was passiert denn z.B. wenn Dein µC Big-Endian hat? Dann wird da ebenfalls nicht das rauskommen was Du erwartest.
Wenn man Daten binär übertragen will muss man sich ziemlich viele Gedanken machen, wenn verschiedene Plattformen beteiligt sind. Alternativ könntest Du die Daten auch als ASCII-Stream verschicken. Da bist Du auf der sicheren Seite.

Diese Variante ist dem reinterpret_cast auf jeden Fall vorzuziehen:

float test=12.5;
unsigned char wert[sizeof(test)];

memcpy(wert,&test,sizeof(test));

Btw: Hat eigentlich jemand eine Idee, wie man die Endianess zur Compilezeit herausbekommen kann? Geht das überhaupt ohne irgendwelche defines?

Hat eigentlich jemand eine Idee, wie man die Endianess zur Compilezeit herausbekommen kann? Geht das überhaupt ohne irgendwelche defines?

Ja.

Hat eigentlich jemand eine Idee, wie man die Endianess zur Compilezeit herausbekommen kann? Geht das überhaupt ohne irgendwelche defines?

Ja.

Dann wäre es auch nett, wenn Du das mal erörtern könntest.

google.de => http://www.allegro.cc/forums/print-thread/592785 irgendwie in der Mitte und am Ende.

Ich sehe da keine Antwort auf die Frage...

However, why not write a mini program (along the lines of Thomas's) to run first and output either #define BIG_ENDIAN or #define LITTLE_ENDIAN to a .h file, then include that file in your main program. It would be easy to incorporate this into a makefile.

Und nenne es dann nicht #define ... sondern const bool endian or whatever.

However, why not write a mini program (along the lines of Thomas's) to run first and output either #define BIG_ENDIAN or #define LITTLE_ENDIAN to a .h file, then include that file in your main program. It would be easy to incorporate this into a makefile.

Und nenne es dann nicht #define ... sondern const bool endian or whatever.

Hmm, das ist zwar eine Möglichkeit, aber leider lässt sich das nicht in den Buildprozess meiner Firma integrieren...

Naja, welche Vorteile ergeben sich denn, wenn du es zur Kompilezeit festellen kannst, anstatt einfach zur Laufzeit?

Ich kann dann via Template-Metaprogrammierung Funktionen zum Konvertieren in ein portables Format und zurück festlegen.
Am Ende würde ich dann z.B. nur noch serialize und deSerialize aufrufen. Die Vorarbeit (inklusive einiger Typprüfungen) könnte der Compiler erledigen.

Man kann das machen, aber das ist a)nicht portabel und b)kann man sich damit u.U. Probleme einfangen (Alignment). Das letztere ist bei gängigen Plattformen zwar meistens unproblematisch, aber trotzdem...
Was genau willst Du denn damit erreichen?

Alignment-Probleme kann man keine bekommen wenn man NACH char* castet. VON char* ist wieder ein anderes Thema...

Tachyon schrieb:

Man kann das machen, aber das ist a)nicht portabel und b)kann man sich damit u.U. Probleme einfangen (Alignment). Das letztere ist bei gängigen Plattformen zwar meistens unproblematisch, aber trotzdem...
Was genau willst Du denn damit erreichen?

Alignment-Probleme kann man keine bekommen wenn man NACH char* castet. VON char* ist wieder ein anderes Thema...

Naja, aber wenn man was serialisiert, muss man das typischerweise auch wieder deserialisieren.

knivil schrieb:

Dann musst du doch schauen, ob der Compiler dir einige defines liefert. C++ von Haus aus, als auch Templates erfahren nie was von der Endianess. Das ist systemspezifisch und ausserhalb der Reichweite von C++. Die vorgestellte Loesung ist auch die einzige, die mir einfaellt. Leider funktioniert sie nicht bei cross compiles. Hier ist was aehnliches: klick

Jo, anders geht es wohl nicht. Ich finde es aber schade, dass der Standard keine Möglichkeiten zum Checken der Endianess vorschreibt. Viele Dinge, die aus numeric_limits<> rauspurzeln sind ja auch Implementation Defined. Und man benötigt die Information ja auch schon öfters mal. Man schaue sich z.B. mal die ganzen Netzwerkprotokolle an...