3. unbestimmter bereich

unbestimmter bereich

  • J

    Der Empfänger der Daten ist ein Microcontroller. Die daten sende ich über eine Peak Systems pcan PCI karte.

    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.

    0
  • T

    JBOpael schrieb:

    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?

    0
  • K

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

    Ja.

    0
  • T

    knivil schrieb:

    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.

    0
  • K

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

    0
  • T

    knivil schrieb:

    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...

    0
  • K

    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.

    0
  • T

    knivil schrieb:

    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...

    0
  • K

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

    0
  • B

    Bei Sockets gibt's doch htonl und Weitere, so was ähnliches würde ich auch einfach machen (oder gleich htonl/... benutzen).

    0
  • T

    knivil schrieb:

    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.

    0
  • K

    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

    0

  • 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...

    0
  • T

    hustbaer schrieb:

    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...

    0
Anmelden zum Antworten