Hallo Leute!
Ich habe ein Int-Array das ist z. B. so gefüllt ist
[10000;-10000;5000;-2344;...;x]
Nun zu meinem Problem. Der Int-Datentyp besteht doch aus 2 Byte. Ich
möchte nun die zwei Bytes aus dem Int-Array ausgewählter Zahlen auslesen
und in ein char-Array schreiben.
Ich vermute man macht das am besten mit Zeigern, aber damit kenne ich
mich noch nicht so gut aus.
Würde mich über einen Hinweis freuen.
mfg Jakob
erstens Zeiger lernen, zweitens die Suchfunktion benutzen - das
Thema gibt es hier etwa 15456 mal.
1
charcarr[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
intaiIrgendwas[NUM_EL_INT];
2
charpcMirGraust=(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 */
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:> 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 :-)
Nun habt ihr mich etwas verwirrt.
also warum sollte der int in C nicht 2 Byte lang sein?
Und ja es soll eine schnelle Methode sein, da sind doch Zeiger genau
richtig oder nicht?
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ß.
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.
Klaus Wachtler schrieb:> char carr[2];> carr[0] = ((char *)&intarr[i])[0];> carr[1] = ((char *)&intarr[i])[1];
Hallo ich habe das so gemacht und er gibt mir ein Herz :) aus. Ich
dachte da kommt irgendwie eine Hexzahl heraus?
Dem Problem mit der Bytelänge bei int, kann ich doch umgehen wenn ich
einfach short nehme oder?
Du musst dir schon überlegen wie du den char ausgibst:
printf("%c", chrr[0]); -> Zeigt dir das Ascii Zeichen an (das Herz).
printf("%d", chrr[0]); -> Zeigt dir den Dezimalwert an.
printf("%x", chrr[0]); -> Zeigt dir den Hexadezimalwert an.
Und tu dir bitte den Gefallen und benutze definierte Datentypgrößen
(int16_t).
Bei einem int und short ist nur sicher das sie mindestens 16 Bit haben,
sowie das ein long mindestens so groß ist wie ein int, aber mindestens
32 Bit hat.
Daraus hat sich auf 16-Bit Systemen die Praxis eingebürgert char, short,
int und long die Größen 8, 16, 16, 32 zu geben; auf 32-Bit Systemen
jedoch 8, 16, 32, 32.
Aber drauf verlassen das ein short oder int jetzt 16 oder 32 Bit hat,
kannst du dich nicht!
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 :-)
Klaus Wachtler schrieb:> Auch nicht mit stdint.h?>>>> Dann definiere es dir selber an einer Stelle und schreibe den Rest ohne>> int.
auch mit dem stdint.h nicht.
Wie stelle ich das an?
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.
Klaus Wachtler schrieb:> Defensives Programmieren
Leider klingt das so langweilig, dass Jungspunden (ok, ist
Ansichtssache) wie mir dabei die Füsse einschlafen ;)
Könnt ihr alten Hasen da vielleicht ein "cooleres" Wort für finden?
Klaus Wachtler schrieb:> Bevor du übrigens mit ganz wilden Konstruktionen liebäugelst,
DAS klingt doch schon viel reizvoller, wer möchte nicht Beherrscher
"wilder Konstrukte" sein? ;)
@Jakob
Sorry, mein Beitrag ist sicher keine große Hilfe für dich gewesen.
Klaus Wachtler schrieb:> Jakob schrieb:>> Ich kenne die Grundlagen von C und habe meine Schwierigkeiten damit.>> Dann kennst du dir Grundlagen nicht genug :-)>
Damit hat Klaus aber das Wesentliche gesagt. Wenn dann noch Fragen
auftauchen, immer her damit.
Die Ausgabe macht:
0 //ja alles klar
1 //ja alles klar
2 //ja alles klar
4000 //ja alles klar
FFFFC000 //nein ich erwarte C000 2Byte das sind 4 Byte !?
0 //ich erwarte 4000
Warum klappt das nicht bei werte[4] und test[0] ?
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.
ja stimmt das ist nicht richtig mit Byte und der 4000.
Ich wälze mich mal durch die Grundlagen. Wenn ich irgendwo hänge frage
ich halt noch mal nach :)
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