3. signed char / unsigned char / char

signed char / unsigned char / char


  • nur zum umwandeln von daten <-> byte/char

    oioioi, dann schreib dir doch einfach ne eigene kleine klasse die das macht. und besser macht als sf::Packet.
    die 2 1/2 zeilen sollte dir das wert sein.

    0
  • *

    Ich will ja auch sowas wie endianess beachten und dann ist es nicht mehr ganz so trivial.

    Dann muss man evtl. noch bytes swappen (oder htonl/htons etc. bemühen) usw..
    Aber drüber nachgedacht hatte ich auch schonmal, evtl. mach ich das.

    Hat gerade wer code zum htonl selbst machen (bytes swappen) parat?

    0
  • 3
     

    template <typename T>
void swap_endianess(T* src, T* dest)
{
    char* s = reinterpret_cast<char*>(src);
    char* d = reinterpret_cast<char*>(dest);

    for(int i = 0; i < sizeof(T); ++i)
        d[i] = s[length - i - 1];
}

    Verwendung:

    int i = 42;
int j;
swap_endianess(&i, &j);
    0
  • *

    Danke dafür.

    Dann fehlen aber nochn paar Sachen.
    Also erstmal muss man die eigene Endianess rausfinden.
    Und wie ist das mit float/double, müssen die auch geswapped werden?
    Bei SFML werden die NICHT geswapped.

    0
  • 3
     

    bool little_endian()
{
    int i = 1;
    return *reinterpret_cast<char*>(&i) == 1;
}

    Außerdem frage ich mich, wie ich nur so eine hässlichen Umwandlungs-Funktion schreiben konnte. Hier nochmal eine schönere:

    template <typename T>
T swap_endianess(T t)
{
    char* data = reinterpret_cast<char*>(&t);
    std::reverse(data, data + sizeof(T));
    return t;
}

    bzw hier inplace:

    template <typename T>
void swap_endianess(T& t)
{
    char* data = reinterpret_cast<char*>(&t);
    std::reverse(data, data + sizeof(T));
}

    😃

    0
  • C
    Mod

    Im Prinzip ist das Ganze in dieser Form ohnehin Unfug: Ein T ist im Allgemeinen nach einem swap kein T mehr.

    0
  • 3

    camper schrieb:

    Im Prinzip ist das Ganze in dieser Form ohnehin Unfug: Ein T ist im Allgemeinen nach einem swap kein T mehr.

    Da das nur mit PODs so funktioniert, ist er das schon. 😉
    Wobei ich die Typen, die ich da durchgejagt habe, auch nicht mehr anrühren würde. Ich verwende diese Funktionen zum Konvertieren nach Big Endian auch für floats und doubles, da ich Big Endian senden muss.

    0
  • T

    Man könnte die Bytes auch direkt in umgekehrter Reihenfolge in die Ausgabe schreiben.

    0
  • 3

    TyRoXx schrieb:

    Man könnte die Bytes auch direkt in umgekehrter Reihenfolge in die Ausgabe schreiben.

    Was sich super auf die Datenrate auswirkt.

    0
  • T

    314159265358979 schrieb:

    TyRoXx schrieb:

    Man könnte die Bytes auch direkt in umgekehrter Reihenfolge in die Ausgabe schreiben.

    Was sich super auf die Datenrate auswirkt.

    Den verstehe ich jetzt nicht.

    Ausgabe ist hier der Sendepuffer. Das was bei SFML wohl sf::Packet heißt.

    0
  • 3

    Puffer != direkt 😉
    Aber ich verstehe, was du meinst. Kleines Missverständnis.

    0
  • T

    Mit direkt wollte ich ausdrücken, dass keine Hilfsvariable gleichen Typs genommen wird, um die Bytes umzudrehen. Da die Bytes ohnehin in den Puffer kopiert werden müssen, kann man die Konvertierung auch dabei erledigen.

    0
  • 3

    TyRoXx schrieb:

    Mit direkt wollte ich ausdrücken, dass keine Hilfsvariable gleichen Typs genommen wird, um die Bytes umzudrehen. Da die Bytes ohnehin in den Puffer kopiert werden müssen, kann man die Konvertierung auch dabei erledigen.

    Schon verstanden 😉
    Allerdings denke ich, dass der Compiler das sowieso dahingehend optimieren wird.

    0
  • *

    314159265358979 schrieb:

    Ich verwende diese Funktionen zum Konvertieren nach Big Endian auch für floats und doubles, da ich Big Endian senden muss.

    Warum musst du das? Wir könnten doch auch in little-endian senden.
    Afaik haben x86 little endian.
    Ich weiß zwar das die "Host-Network-Order" Big-Endian ist, aber wieso das so ist und warum man sich daran halten "muss" verstehe ich nicht.

    0
  • 3

    Weil der Server, zu dem ich sende, nunmal Big-Endian liest. Da muss ich nunmal umwandeln. Java ftw!

    0
  • *

    Ok, solche Probleme hab ich nicht 🙂

    Ich wollte das dann ungefähr so einsetzen:

    bool isLittleEndian() 
{ 
    int i = 1; 
    return *reinterpret_cast<char*>(&i) == 1; 
}

template <typename T> 
void swapEndianess(T& t) 
{ 
    char* data = reinterpret_cast<char*>(&t); 
    std::reverse(data, data + sizeof(T)); 
}

template <typename T> 
void toBigEndian(T& t)
{
    if(isLittleEndian())
	{
		swapEndianess(t);
	}
}

template <typename T> 
void fromBigEndian(T& t)
{
	if(isLittleEndian())
	{
		swapEndianess(t);
	}
}

    Mir fällt gerade auf das
    toBigEndian == fromBigEndian.

    0
  • *

    314159265358979 schrieb:

    Ich verwende diese Funktionen zum Konvertieren nach Big Endian auch für floats und doubles, da ich Big Endian senden muss.

    Bist du dir wirklich sicher, dass float und double auch von endianess betroffen sind?

    SFML macht da keine konvertierung.
    QT auch nicht, wenn ich das richtig verstehe:
    http://doc.qt.nokia.com/latest/qtendian.html

    T qFromBigEndian ( const uchar * src )

    Reads a big-endian number from memory location src and returns the number in the host byte order representation. On CPU architectures where the host byte order is little-endian (such as x86) this will swap the byte order; otherwise it will just read from src.

    Note: Template type T can either be a qint16, qint32 or qint64. Other types of integers, e.g., qlong, are not applicable.

    Also scheints für float/double nicht zu funktionieren, was dafür spricht, dass es dabei nicht nötig ist.
    Weiß da wer mehr?

    Und QT hat sowohl fromBigEndian als auch toBigEndian, bei mir hatte beides den selben code, kann das so stimmen?

    0
  • 3

    Ich sende zu einem Java-Server, der verwendet Big Endian. Wie alles in Java.

    0
  • *

    Ich weiß, es ging mir darum, ob es das Endianess-Problem nur für Ganzzahl-Typen, oder auch für Fließpunktzahlen gibt.
    Habe dazu aber gerade noch das hier gefunden:
    http://stackoverflow.com/questions/2782725/converting-float-values-from-big-endian-to-little-endian/2782742#2782742
    Also scheint es für float/double doch auch nötig zu sein das zu beachten.

    Edit:
    Auf einem Little-Endian-Rechner wird java aber doch wohl nur bei IO in big-endian umrechnen und nicht immer damit rechnen, oder?
    Ansonsten würde das doch totalen overhead erzeugen.

    Und was war mit toBigEndian/fromBigEndian identisch, stimmt das so?

    0

  • 314159265358979 schrieb:

    Ich sende zu einem Java-Server, der verwendet Big Endian. Wie alles in Java.

    Java selbst (core language) hat soweit ich weiss kein Konzept von Endianness. Diverse Serialisierungs-Klassen definieren dann welche Endianness verwendet wird.
    Und JNI wird, schätze ich mal, die selbe Endianness verwenden wie die CPU bzw. das OS das die VM hostet. Wäre ziemlich doof wenns anders wäre.

    0
Anmelden zum Antworten