Bytes auslesen und in ein Array schreiben "C"

erstens Zeiger lernen, zweitens die Suchfunktion benutzen - das
Thema gibt es hier etwa 15456 mal.

1

    char carr[2];

2

    carr[0] = ((char *)&intarr[i])[0];

3

    carr[1] = ((char *)&intarr[i])[1];

Jakob schrieb:
> [10000;-10000;5000;-2344;...;x]

Das ist aber kein C.

Jakob schrieb:
> Der Int-Datentyp besteht doch aus 2 Byte.

Kann sein, muß nicht - je nach Compiler.

Jetzt verrat mir mal einer, warum hier zum Teufel immer verquastere und 
implementationsabhängigere Codevarianten auf so ein gängiges Problem 
losgelassen werden. Wieviele Gigabytes musst Du denn pro Sekunde 
umkodieren?

Wenn es absolut auf Geschwindigkeit ankommt, dann doch gleich jede Scham 
über Bord geworfen und so:

1

int aiIrgendwas[NUM_EL_INT];

2

char pcMirGraust = (char*)aiIrgendwas;

3

4

aiIrgendwas[0] = 4711;

5

/* pcMirGraust[0] und pcMirGraust[1] können Daten enthalten, die was mit 4711 zu tun haben */

Wenn Du irgendwie Kontrolle über das behalten willst was Du da tust, 
solltest Du so etwas tun:

1

#include "MISRATYPES.H" /* Oder wie auch immer das in Deiner Welt heisst */

2

3

int16_t ai16Irgendwas[NUM_EL_INT];

4

uint8_t  au8Serialisiert[NUM_EL_INT*2];

5

6

for (int i=0; i<MUM_EL_INT; ++i)

7

{

8

  au8Serialisiert[i*2]   = (uint8_t)(ai16Irgendwas[i]&0xFF);

9

  au8Serialisiert[i*2+1] = (uint8_t)(ai16Irgendwas[i]>>8);

10

}

Das ist wenigstens soweit durchschaubar, Du weißt immerhin, wo High- und 
wo Low-Byte stehen, etc. Aber natürlich ist der Code a) lesbar und b) 
nicht superperformant, also überhaupt kein richtiges C sondern nur 
verkleidetes Pascal...

Aber das schreib ich nur, weil ich weiß, dass es keinen interessiert. 
Ich lebe ja davon derartige Schlampigkeiten zu suchen.

Grüße,
  Stefan

Stefan Hennig schrieb:
> #include "MISRATYPES.H" /* Oder wie auch immer das in Deiner Welt heisst */

stdint.h heisst das normgerecht.

Stefan Hennig schrieb:
> Jetzt verrat mir mal einer, warum hier zum Teufel immer verquastere und
> implementationsabhängigere Codevarianten

Über Geschmack kann man streiten.
Aber erstens wollte der TO eine Zeigerlösung haben, zweitens: wo
bitte ist das (von der Vorgabe sizeof(int)==2 abgesehen)
implementationsabhängig?

Stefan Hennig schrieb:
> Wenn es absolut auf Geschwindigkeit ankommt, dann doch gleich jede Scham
> über Bord geworfen und so:int aiIrgendwas[NUM_EL_INT];
> char pcMirGraust = (char*)aiIrgendwas;
>
> aiIrgendwas[0] = 4711;
>

So wird es jedenfalls nicht gehen, was deine Abneigung gegen
Zeiger natürlich bestätigt :-)

Stefan Hennig schrieb:
> Ich lebe ja davon derartige Schlampigkeiten zu suchen.

Das nehme ich natürlich persönlich :-)

Jakob schrieb:
> also warum sollte der int in C nicht 2 Byte lang sein?

Weil er es auf 32-Bit-Systemen (ARM, x86 etc.) nicht ist, da ist ein int 
4 i.d.R. vier Bytes groß.

Und Stefan hat da vollkommen recht:
Wenn man sich auf 2 Bytes verlässt, dann ist int16_t
bzw. uint16_t der richtige Typ.

Klaus Wachtler schrieb:
> Stefan Hennig schrieb:
>> Ich lebe ja davon derartige Schlampigkeiten zu suchen.
>
> Das nehme ich natürlich persönlich :-)

Danke für das Smiley. Persönlich wars bestimmt nicht gemeint.

Mein Beispielcode ist natürlich falsch, mindestens fehlt ein 
Pointer-Stern.
Ansonsten bitte ich, meine unterschwellige Gereiztheit zu entschuldigen, 
ich bin im Moment neben dem üblichen Weihnachtsstress noch im 
Projektstress, der sich zumindest etwas hätte abmildern lassen, wenn 
jeder, sagen wir, etwas defensiver programmiert hätte und nicht immerzu 
irgendwelche Annahmen über irgendetwas gemacht hätte, das im vor-vorigen 
Projekt wahr gewesen sein mochte.

Nichts für ungut,
   Stefan.

Habe ich auch nicht so ernst genommen, aber Pfusch lasse ich
auch nicht gerne auf mir sitzen.
Sonst bin ich nicht eitel, aber da manchmal schon (was nicht
davor schützt, trotzdem Fehler zu machen - leider).

Defensives Programmieren kann ich aber auch jederzeit unterstützen,
dagegen sage ich gar nichts.

Oder umgekehrt wenn es denn int sein soll:

1

    union

2

    {

3

        int           i;

4

        unsigned char c[sizeof(int)];

5

    } int_oder_char;

6

    int_oder_char.i = 4711;

7

    // in int_oder_char.c[0] bis int_oder_char.c[sizeof(int)-1] stehen jetzt die Bytes

Und schon gar nicht, unter keinen Umständen, nimmt man den Datentyp 
'char' her, wenn man mit Bytes arbeitet!


Am besten gewöhnt man sich von vrne herein gleich mal die Sichtweise an, 
dass es in C 3 verschiedene Character-Datentypen gibt


    char
    signed char
    unsigned char


Aber auch hier bevorzugt man für die letzten beiden die Schreibweise 
int8_t bzw uint8_t

Jakob schrieb:
> ich würde gerne mit uint16_t arbeiten, aber mein compiler kennt das
> nicht

Auch nicht mit stdint.h?

Dann definiere es dir selber an einer Stelle und schreibe den Rest ohne 
int.

Karl heinz Buchegger schrieb:
> Am besten gewöhnt man sich von vrne herein gleich mal die Sichtweise an,
> dass es in C 3 verschiedene Character-Datentypen gibt
>
>
>     char
>     signed char
>     unsigned char

Hast du das schon auf einer Funktionstaste liegen?
Irgendwie kommt es mir bekannt vor :-)

Oben im Quelltext:

1

#include <stdint.h>

Und ab dann munter int8_t, uint8_t, int16_t, uint32_t, int32_t, uint32_t 
... verwenden.

Wenn das nicht geht, würde ich gerne wissen, mit welchem Conmpiler es 
nicht gehen soll.

Bevor du übrigens mit ganz wilden Konstruktionen liebäugelst,
wäre es förderlich, auch mal die Grundlagen von C anzuschauen.
Das erspart allen Beteiligten viel Arbeit, auch dir.

Es gibt einen besseren Weg:
stdint.h ist bei VS2005 tatsächlich nichtz mit in der Installation, man 
kann es aber nachrüsten:
http://msinttypes.googlecode.com/svn/trunk/stdint.h

Diese Datei zu den anderen Include-Dateien kopieren und es sollte gehen.

Jakob schrieb:
> Ich kenne die Grundlagen von C und habe meine Schwierigkeiten damit.

Dann kennst du dir Grundlagen nicht genug :-)

Klaus Wachtler schrieb:
> Diese Datei zu den anderen Include-Dateien kopieren und es sollte gehen.

Nachtrag: bei der Gelegenheit kann man auch gleich
http://msinttypes.googlecode.com/svn/trunk/inttypes.h
dazukopieren.

Jakob schrieb:
> Ich kenne die Grundlagen von C

dann sind deine Grundlagen nicht grundlagig genug.

Jakob schrieb:

> 4000 //ja alles klar
> FFFFC000 //nein ich erwarte C000 2Byte das sind 4 Byte !?

Das ist aber printf egal.
printf erwartet bei %x einen int. Und ein int ist auf deinem PC nun mal 
4 Bytes groß


> 0    //ich erwarte 4000

Solange du das weiter oben Gesagte über den Datentyp char nicht 
beherzigst wird das nichts. Des weiteren wirst du mit 4000 in einem Byte 
sowieso Schiffbruch erleiden. 256 ist das Maximum.

... , was bedeutet daß deine 2 Byte ausgegeben werden zusammen
mit 2 Byte, die gerade im Weg stehen (direkt daneben), bzw. deine
2 Byte auf 4 aufgeblasen werden.

Karl heinz Buchegger schrieb:
> Jakob schrieb:
>> 0    //ich erwarte 4000
>
> Solange du das weiter oben Gesagte über den Datentyp char nicht
> beherzigst wird das nichts. Des weiteren wirst du mit 4000 in einem Byte
> sowieso Schiffbruch erleiden. 256 ist das Maximum.

Das würde hier noch passen: ein Byte ist 0, dass andere 64.

An den TO: Null kommt raus, da die Byte-Reihenfolge nicht Big-Endian, 
sondern Little-Endian ist d.h. ((char *) &werte[3])[1] == 0x40

ja, hast du.

Ob das alles Sinn macht, bezweifle ich bauchmäßig irgendwie, aber danach
hattest du nicht gefragt.