3. unsigned char * zu string

unsigned char * zu string

  • M

    Deswegen habe ich mein **unsigned char *** auf unsigned char gecastet. Dann wird das Ganze auch compiliert. Allerdings stimmt das Ergebnis halt nicht. Die andere Variante funktioniert, bis auf das Problem mit der Länge.
    Es ein **unsigned char *** weil ich Pakete von einem Gerät über R232-Schnittstelle lese, die nun mal unsigned sind.

    0
  • P

    Ok, welcher art sind denn die packete? Da du sie in einen string packen willst sind es ebenfalls strings oder ? Dafür spricht auch dass sie 0-terminiert sind.
    Die frage ist ob du information verlieren würdest wenn du in char* convertieren würdest.

    Kannst du darauf nochmal eingehen ?

    0
  • M

    Hmm,

    sagen wir mal so, an den Daten so wie ich sie bekomme ist nichts zu rütteln. Da ich sie erst interpretieren muss, um zu wissen, wie sie aussehen. Das Problem wie ich's beschrieben habe, tritt nur bei bestimmten Arten von Paketen auf, die dann aus einem Header bestehen und einem Ascii-String.
    Es gibt dann wieder andere Pakete, die man als structs interpretieren kann.
    Sie haben nur eins gemeinsam. Den Header, aus dem ich sehen kann, was genau da durchkommt, und der Eigenschaft, dass die Pakete unsigned sind.
    Aber eigentlich sollte das unsigned kein Problem darstellen.

    0
  • M

    Also zurück zu meiner ersten Frage. Kann ich stringstream so manipulieren, dass ich nicht das Ende einer vorherigen längeren Nachricht drin hab?
    (Das Einfügen von "HStrg << "\0"" hat keine Auswirkung auf HStrg.str())

    0
  • S

    Warum rufst du nicht einfach string.clear() auf, dann kannste sicher sein, dass der neue Inhalt länger ist als der alte, weil der ja "" ist.
    Oder Missversteh ich dein Problem völlig?
    Und Anhängen kannst du ja eifnach mit += , was auch für char pointer geht, wenn du

    string += std::string(charpointer)

    machst

    0
  • B

    Du kannst den stringstream ja vorher leer machen (mit HStrg.str(""); ).

    0
  • M

    [Edit]@Slin:
    Du hast das Problem verpasst. Es geht darum, dass das Ende der längeren Nachricht noch in stringstream steckt. Wie ich mit string umgehen muss ist mir schon klar.

    0
  • P

    Achso jetzt versteh ich das.

    Du bekommst einen bytestrom also im prinzip wie ja auch schon anfangsgeschrieben einen unsigned char *

    Der sieht so aus:

    [code]
    header \0 daten
    [code]

    Du interpretierst also den teil des packets von packet[0] bis zum terminierer als string und den rest als irgendwas. Was das ist sagt dir der header. Soweit richtig ?

    Ok dann bau dir doch den string folgendermaßen.

    string extract_header(const unsigned char *buffer){
 string header;
 while(*buffer)
   header+=(char)*buffer++;
 return header;
}

    Und dann einfach ausgabe und anhängen mit dem string.

    0
  • M

    @Prolog:

    Also das hört sich zwar sehr durchdacht an, funzt aber nicht so. Ich habe das schon in ähnlicher Form versucht.
    Es ist so. Der Strom sieht ungefähr so:

    ba ab 01 00 17 00 01 00 [...]
    (umgedreht ergibt das erst Sinn. Nennt sich glaube ich "big-endian".)

    Die ersten zwei Byte sind der Anfang. Die nächsten zwei Byte sind die PacketID, danach die 2 Bytes sind die Anzahl von Bytes im optionalen Teil der Nachricht und danach die 2 Bytes zeigen mir, dass das ein Datenpaket ist. Allerding hab ich jetzt noch nicht alles vom Header aufgeschrieben. Es kommen dann noch eine MsgID usw. Die Teile sind auch nicht immer 2 Byte gross, sondern auch man 4 oder 1.
    Das heisst also am Anfang Bytes zählen, auswerten und entscheiden, wie der Rest ausgewertet werden soll.
    Bei der Abbruchbedingung meiner Schleife funktioniert, weil die ASCII-Strings nullterminierend sind.

    @Braunstein:
    Deinen Vorschlag hab ich probiert. Funktioniert aber nicht. Aber vielleicht hätte ich auch das HStrg.seekp(0); weglassen sollen. Muss ich nochmal probieren.

    @Slin:
    Schonmal gelesen was stringstream::clear() macht?

    0
  • P

    Wenn du weisst wie das packet formal aussieht, kannst du dir eine struktur schreiben die der spezifikation entspricht und sie einfach drauf casten.

    Das wird in der netzwerkprogrammierung auch so gemacht.

    0
  • M

    Ich weiss. Mache ich ja an einigen Stellen auch so.

    Maffe001 schrieb:

    [...]
    Es gibt dann wieder andere Pakete, die man als structs interpretieren kann.
    [...]

    Nur bei dem ASCII-String scheint mir das nicht notwendig zu sein.
    Vielleicht sollte ich HStrg in der Schleife deklarieren, so dass er bei jedem Umlauf neu erzeugt wird. 👎 Allerdings wollte ich darauf verzichten.

    0
Anmelden zum Antworten