C++ .. ne Zahl an was dranhängen

datagram[x] = LEDNr;

x ist durch Auszählen zu bestimmen. Das ganze muss natürlich nach dem 
memcpy geschehen und geht nur, wenn die Position fest ist, also der 
String davor unveränderlich.

Hat sich eigentlich schon mal jemand diese merkwürdige Stringkonstante 
näher angesehen, die da per memcpy kopiert werden soll? Die ist, wenn 
ich mich nicht völlig verzähle, gerade mal 8 Bytes lang; memcpy wird 
aber angewiesen, 16 Bytes zu kopieren.

Als Argument für sprintf eignet sich dieser String gar nicht, da die \0 
als erstes Zeichen den String bereits terminiert, sprintf also die 
Formatanweisung nicht versteht.

Aber selbst wenn es das täte, wäre die Formatanweisung fehlerhaft, 
anstelle %u müsste schon %c verwendet werden.

Danke!

Datagramm ist kein String, sondern ein Array von chars. Da macht sprintf 
wenig Sinn. Die LED Nummer ist im obigen Beispiel mit einem Backslash 
geschrieben, d. h. es ist offenbar gerade keine literale Interpretation 
der LED Nummer gewünscht, sondern der Wert selbst (obwohl \ mit 
dezimaler Notation eigentlich nicht auftreten dürfte).

Wenn er ein Backslash übertragen will, müsste er es im String doppelt 
schreiben.

Davon abgesehen kann man natürlich erstmal einen String bauen, in dem 
alles sauber drinn steht - dort kann man dann auch mit sprintf operieren 
- und danach alles nach Datagramm kopieren. Ist die sauberste, 
wartbarste, zur Laufzeit vermutlich uneffizientest und 
"hochsprachlichste" Lösung.

Punkt 1 ist aber die Klärung, wie die Zahl dort gewünscht wird, in ASCII 
Repräsentation oder nicht.

> Warum aber der Integer LEDNr durch sprintf als char interpretiert
> werden soll ist mir ein Rätsel??? !

Oh. Das muss es nicht. Auch ein char ist letztendlich ein
skalarer Typ, der eine ganze Zahl repräsentiert. Der wichtiste
Unterschied (neben seiner Größe) besteht darin, dass char und
int während Ausgaben / Eingaben (und natürlich bei der damit
zusammenhängenden Formatierung) anders behandelt werden.
Während bei einem int durch Verwendung von %d oder %u oder ...
eine Konvertierung der Zahl in eine ASCII Repräsentierung erzwungen
wird, wird bei der Ausgabe als char, erzwungen durch %c, der int
direkt, quasi binär, in den Ausgabestream eingefügt.

> Kann natürlich so sein, ist aber genau so unwahrscheinlich (oder
> wahrscheinlich) wie %u oder %d

Nö. Das ist tatsächlich so.

Zum Rest kann ich nichts sagen, da mir immer noch unklar ist,
wie denn das Ergebnis auf Byteebene aussehen soll. Der springende
Punkt ist immer noch der: Soll die LedNr als ASCII-Repräsentierung
der Zahl eingebaut sein oder soll im Datagramm der binäre Wert
der LedNr auftauchen.

Wenn ich was vorschlagen darf:
Denk dir für die binäre \0 was anderes aus.
Irgendwann benutzt du string Funktionen dafür,
warum auch nicht, und dann ist dir diese \0 ewig im Weg.

Du könntest zb folgendes machen:

#define SET_LED_FUNCTION 3

void usbInterface_LPC2148::methodSwitchLEDOn ( int LEDNr )
{
  BYTE datagram[16];
  sprintf( datagram, "%csMI%c%c", '\0', SET_LED_FUNCTION, LedNr );
  usbInterface::write( datagram );
}

Das zusätzliche Argument '\0' zu sprintf ist zb. nur deswegen
notwendig, weil du '\0' so nicht in den Format-String einbauen
kannst.

Wenn du auf die str... Familie verzichten willst, dann musst du
selbst auf die Längen acht geben. So was wie:

  memcpy( datagram, ("\0sMI \3 \5"), 16 );

ist kein Kavaliersdelikt! Der String "\0sMI \3 \5" ist nun mal
keine 16 Zeichen lang. Genau genommen, hat er als String eine
Länge von 0 Bytes (wieder: wegen dem \0 da ganz am Anfang).
Man könnte auch argumentieren, dass er ein deklarierte Länge
von 9 Bytes besitzt. Wie auch immer: Er ist auf jeden Fall
keine 16 Bytes lang.

sprintf will als ersten parameter einen char *, du gibst ihm einen BYTE 
*.

BYTE ist bei dir warscheinlich ein typedef auf unsigned char...

Wobei ich immer noch nicht verstehe, warum sich JEDER eigene Typedefs 
für solche int-Datentypen baut, wo's doch mit #include <stdint.h> 
schöne, standartisierte gibt, z.B. uint8_t, int8_t, int32_t usw...

/Ernst

sprintf( static_cast<char *>(datagram), "%csMI%c%c", '\0', 
METHOD_SET_LED, LEDNr ); // C++ style cast

oder

sprintf( (char *)datagram, "%csMI%c%c", '\0', METHOD_SET_LED, LEDNr ); 
/* C style cast */

Na, du könntest direkt in dem sprintf-Aufruf datagramm auf char* casten. 
Allerdings nur, wenn du dir sicher bist, da die Datentypen soweit 
kompatibel sind, dass nix passiert.

Ansonsten wäre zu empfehlen, diese PASCAL-Style Typedefs nicht zu 
verwenden ;-)

Nils wrote:

> error C2440: 'static_cast' : cannot convert from 'BYTE *' to 'char *'

Das darf eigentlich nicht sein, wie ist den dein "BYTE" deklariert?