Aus 1 Byte ein Word erstellen ?

$23 um 16 Bit nach links schieben. Platz sollte da sein.

Joachim D. schrieb:
> 16 Bit nach links schieben

echt? rechne noch mal nach!

Überraschung ;)

Die Bezeichnug "word" wurde im Lauf der Jahre viel zu unscharf, 
Mißverständnisse sind quasi vorprogrammiert. Ich versuche diese 
Gummi-Typen nicht nur im Code sondern auch in begleitendem Text zu 
vermeiden so gut es geht. Selbst in Pascal (obwohl es dort als Datentyp 
sauber definiert ist) benutze ich es nicht mehr sondern stattdessen 
UInt16/Int16 um Nicht-Pascalern beim Lesen keine unnötigen Fragezeichen 
oder gar falsche Vorstellungen in den Kopf zu pflanzen.

Bernd K. schrieb:
> UInt16/Int16 um Nicht-Pascalern beim Lesen keine unnötigen Fragezeichen
> oder gar falsche Vorstellungen in den Kopf zu pflanzen.

Dafür wird dich ein "Pascaler" fragen ob .....

> in Pascal (obwohl es dort als Datentyp
> sauber definiert ist)

Max M. schrieb:

> Dafür wird dich ein "Pascaler" fragen ob .....
>
>> in Pascal (obwohl es dort als Datentyp
>> sauber definiert ist)

In FPC ist word immer 16 bit. Delphi auch. Das sind die beiden Dialekte 
die heute noch am weitesten verbreitet sind, alles andere was heute noch 
lebt sind Nischenerscheinungen. Kennst Du einen bei dem word breiter ist 
als 16 Bit?

Und selbst wenn: Genau aus dem Grund weil dann wieder einer kommt und 
zweifelt nehm ich NICHT word und stattdessen lieber Datentypen mit 
unmißverständlcihen Namen wo ich kann, mir gehts ja gerade auch um Leser 
die nicht auswendig wissen wie breit das jetzt hier und heute zufällig 
ist, ein Datentyp mit der Zahl 16 im Namen wird im Lauf der Zeit nicht 
stillschweigend anfangen zu mutieren.

Bernd K. schrieb:
> Die Bezeichnug "word" wurde im Lauf der Jahre viel zu unscharf,
> Mißverständnisse sind quasi vorprogrammiert.

Eigentlich bezeichnet man damit die native Breite des Systems. Viele 
kennen es als 16 Bit, weil x86 ursprünglich mal eine 16-Bit-Architektur 
war und man das dort aus Kompatibilitätsgründen bis heute gleich 
gelassen hat. Wenn man aber z.B. das Datenblatt eines ARM liest, ist ein 
Word dort 32 Bit breit. 16 Bit ist ein Halfword.

FS schrieb:
> Zurück zum TO: "Rechnerisch" würde bedeuten (steht auch schon weiter
> oben), den Wert mit 256 (0xff) zu multiplizieren. In der Praxis löst man
> das aber nicht rechnerisch, sondern schiebt den Wert um 8 bit nach
> links, weil es effizienter ist.

Auf jedem halbwegs optimierenden Compiler sollten diese Operationen zu 
identischem Code führen. Ich würde dennoch den Shift nehmen, weil es die 
Intention besser ausdrückt. Und auf dem PC macht das sowieso selten 
einen signifikanten Unterschied.

Danke für die Info.

Ich werde schieben rechts und links.

Gruss

Peter B. schrieb:
> Danke für die Info.
>
> Ich werde schieben rechts und links.
>
Nur links! ;-)

Nick M. schrieb:
> Und welcher Prozessor?
> Bei 8 Bit ist ein "word" 1 Byte,
> bei 16 bit 2 byte,
> bei 32 bit 4 byte,
> ...

Prozessor ist wurscht, und bzgl Wortlänge:
Lies noch mal die Frage ...

Larry schrieb:
>> Und du hast die originale Post des TO gelesen?
>
> Bis auf den Lapsus, dass nicht das Hi-Word null werden soll,
> sondern das Lo-Word, bleibt es dabei.

Wo meinst du, das gelesen zu haben?

>> Da braucht man nicht mal schieben!

Also hast du es nicht gelesen. Solltest du mal, damit du die 
Aufgabenstellung verstehst.

Larry schrieb:
> C-Programmierer koennen scheinbar nur Ramsch spielen. Sie schieben.

Was hat das denn mit C zu tun? Ich würde da in jeder Sprache schieben.

> Und auf den Optimierer ihres Compilers vertrauen.

Wenn man dem Optimizer nicht trauen darf, dann ist der Compiler Mist. 
Das ist ebenfalls unabhgängig von der Sprache.