[C#] int v byte[] in nazaj

bolj splošna rešitev je:

int i;
byte b[4];

b[0] = ( i & 0xFF000000) >> 24;  
b[1] = ( i & 0x00FF0000) >> 16;
b[2] = ( i & 0x0000FF00) >> 8;
b[3] = ( i & 0x000000FF);

in še obratno..

i = (b[0]<<24) |  (b[1]<<16) | (b[2]<<8) | (b[3]);

Res je - ne poznam C#, sploh pa ne njegovih knjižnic. Zato sem podal splošno rešitev, ki deluje v vseh jezikih, ki poznajo bitne operatorje.

Ravno prejšnji teden sem potreboval to funkcionalnost.
BitConverter je super zadeva, edino problem je, da je objekt Static, in da ima ReadOnly property IsLittleEndian.
In zakaj je to problem? Ker želim komunicirati z neki drugim sistemom, ki ima byte razporejene drugače!
Rešitev? Custom BitConverter - tako kot ga je opisal Quikee z upoštevanjem Little/Big Endian.
BlueRunner: kakšna boljša ideja?

Torej, če rabim zadevo za zapis v datoteke, je najbolje, da vseeno uporabim kar opcijo, ki jo je zapisal Quikee?

drola: Uporabi BitConverter raje, kot je predlagal BlueRunner. Zelo dvomim, da se bodo tvoje datoteke kadarkoli uporabljale hkrati na little endian in big endian računalnikih. Le v tem primeru bi imel težave.

Potem pa raje naredi

byte[] data = BitConverter.GetBytes(longVar);
if (!BitConverter.IsLittleEndian) Array.Reverse(data);

Oziroma, če želiš biti premeten, potem raje naredi

(byte)((number >> 56) & 0xFF)

Vsekakor pa poskrbi, da bodo tvoje datoteke vedno v istem -endian načinu.

Zgodba z 0xFF00000000000000 pa je malo daljša... Način kako si se lotil težave je sicer lep in delujoč v prevajalniku, kjer se uporablja "mehek" sistem tipov, v malo bolj striktnem pa v ozadju naredi kar nekaj stvari... stvari, ki jih je zelo dobro poznati, če se tega lotiš sam.

V C# obstajata dve pravili, ki urejata implicitno konverzijo številskih tipov. Prva je večanje: byte -> short -> int -> long -> float -> double. Drugo pravilo pa pravi, da se nepredznačen tip nikoli ne prevede v enako velik predznačen tip. To pomeni, da byte ne more iti v sbyte, ushort ne more iti v short, uint ne more iti v int, ulong ne more iti v long. Razlog za to omejitev pa je zapis negativnih števil z dvojiškim komplementom, ki prvi bit (MSB) "spremeni" v bit za predznak. Če bi bila dovoljena konverzija v isti velikosti (32-bitni nepredznačen v 32-bitnega predznačenega), bi to lahko povzročilo nenamerno spremembo predznaka in posledično napačen izračun, na vse skupaj pa nepreviden programer ne bi bil opozorjen. Tretje pravilo, ki se tiče tvoje težave pa je to, da je dovoljeno bitne operacije uporabljati samo na identičnih (enaka velikost in enaka predznačenost - signed,unsigned) operandih. Težava se v tvojem primeru pojavi zato, ker se prevajalnik "pametno" odloča, ali naj bo konstanta predznačena, ali nepredznačena. V tvojem primeru tako vidi vse 0x00...FF.. konstante kot predznačene, razen zadnje, ki ima MSB postavljen na ena, kar mu povzroči, da jo bo prevajalnik "videl" kot nepredznačeno. Zaradi upoštevanja pravila (3), ki programerja varuje pred nenamernimi napakami tako ni možno izvesti operacije '&'.

Vendar pa obstajajo implicitne konverzije, ki jih prevajalnik nediskriminatorno uporablja, ne da bi bil na njih opozorjen. Pri prvem primeru, kjer se je igralo z 32-bitnim številom, je prevajalnik 0xFF000000 (uint) implicitno prevedel v 0x00000000FF000000 (long), drug operand (int) pa je tudi implicitno prevedljiv v višji tip (long). To pomeni, da ti vse deluje pravilno, samo v postopku si naredil eno konverzijo iz 32 bitov v 64 bitov, nato pa si rotiral 2x več bitov, kot bi bilo potrebno, ker se je navidezno 32-bitno operacija "nadgradila" v 64-bitno. Ni ravno hud zaplet, še vedno pa je čisto nepotreben, moteče pa je, da je bila narejena potencialno slaba stvar (predstavljaj si to konverzijo znotraj zanke), na katero pa sploh nisi bil opozorjen.

Pri drugem primeru pa je občutek sicer slabši, vendar pa ne moreš ponoviti iste napake, ravno zato, ker prevajalniku zmanjka implicitnih možnosti(*) za napačno interpretacijo tvojih namenov. Ker implicitna konverzija ne obstaja, to pomeni, da moraš sam povedati na kakšen način boš izvedel operacijo. Zaradi tega uporabiš priredbo tipa (typecast), ki prevajalniku dopove, da si z konverzijo konstante mislil resno (ulong v long), oziroma, da te ne moti, če spremenljivko gledaš kot nepredznačeno (long v ulong). V intuitivnem primeru, kot si ga izbral ti (konstanta iz ulong v long), ostane prevajalnik še vedno bolj pameten, zaradi česar te tudi po typecastu ne mara preveč in ti utruja z zahtevo, da označiš svojo kodo za /unchecked. Vse skupaj pa samo zato, ker prevajalnik ne želi, da mu pišeš predznačene konstante v nepredznačeni obliki(**).

Rešitev je več, najbolj elegantna rešitev, ki sem jo našel za to neumnost pa je točno tisto, kar sem napisal na vrhu... izogni se tako veliki konstanti, tako, da najprej narediš premik, nato pa obrežeš ostanek. Pri največjem bytu pa niti obrezovati ne rabiš, ker ti že sam premik uredi težavo. Na ta način pri 16- in 32-bitnih številih ne povečaš velikosti podatka po nepotrebnem (16-bitna se ti pri number & 0xFF00 "nadgradijo" v 32-bitna, ...), pri 64-bitnih pa vse skupaj deluje brez neprijetnih opozoril. Druga možna rešitev (če vztrajaš pri "obratnem" načinu z velikimi konstantami) pa je, da daš v zadnjem primeru ulong typecast pred spremenljivko, namesto long pred konstanto. Manjši tipi pa bodo potem trpeli zaradi implicitnih konverzij. V teh stvareh so pri preveč "pametnih" prevajalnikih za nekoga, ki je na prehodu med začetnikom in profesionalcem, pač veliko bolj zahtevna, ker, razen poznavanja teorije binarnih števil, zahtevajo tudi poznavanje okolja in prevajalnika samega. Da ne bo pomote, še huje pa je to za "stare mačke", ki prihajajo iz C/C++ jezikov. Sintaksa je skoraj ista, v kaj se to prevede pa je za njih čisto neintuitivno (vsaj zame je bilo), ker ne poznajo logike delovanja. Znova postanejo začetniki, saj jim veliko majhnih trikov veliko bolj škodi, kot pa koristi. Nekaj kar v C-ju izgleda elegantno in deluje optimalno, lahko v drugem jeziku izgleda moteče, delovanje pa je lahko čista katastrofa.

Tudi to pa je eden izmed razlogov, da vedno svetujem uporabo ustrezne metode, če ta že obstaja. Navadno je takšen nasvet zelo dober, ker je za pojasnila kje se kaj dogaja v prevajalniku, v VM okolju, v določenem sistemu, ... potrebno tipkati in tipkati in tipkati, jaz pa nimam vedno dobre volje, da bi razlagal čisto vse, do česar se lahko dokoplje vsak, ki ga tovrstna tematika resnično zanima. Razumem pa zagato tistih, ki imajo projekte, ker imajo projekti roke, roki pa navadno pomenijo, da ni časa niti za poiskati uporabno literaturo, kaj šele čakati na konference, kjer se lahko pogovarjaš naravnost z razvijalci (osebno nimam niti ene knjige na temo .NET okolja ). (Hint: v februarju in marcu imam nekaj lukenj, ki jih lahko za primerno odškodnino ponudim tudi za svetovanje pri konkretnih projektih).

(*) Po mojih izkušnjah prevajalniki vedno naredijo točno tisto, kar je programer želel, vendar pa šele potem, ko izčrpajo vse napačne možnosti.

(**) Osebno mislim, da je to napaka, ki verjetno izhaja iz tega, da so razvijalci okolja po eni strani želeli začetnike obvarovati pred začetniškimi napakami, po drugi strani pa so med razvojem 1.0 verzije originalno precej bolj trd sistem tipov "omehčali" (po zgledu na Javo), pri čemer so na nekaj stvari preprosto pozabili. Če bi bili konsistentni, potem bi typecast konstante zadoščal tudi brez /unchecked zastavice, oziroma bi unchecked zastavico zahtevala katera koli bitna operacija, ki bi lahko potencialno spremenila predznak števila. Premik v desno je recimo deljenje z dva, če pa to narediš na negativnem celem številu, potem to nikakor več ne more biti pravilno deljenje z dva... opozorila prevajalnika in zahteve za /unchecked zastavico pa od nikjer. Vse skupaj pa je še ena lekcija, da če se ubadaš z sistemskimi zadevami, ki se dotikajo arhitekture računalnikov in bitnih operacij, potem moraš v tovrstnih okoljih paziti na čisto druge stvari, kot pa v dobrem starem C-ju.

To, kar si napisal, je najboljši način kako narediti kodo najbolj čitljivo in prenosljivo med različnimi C# prevajalniki, ki prevajajo kodo za CLR. Najbolj optimalna koda iz vidika hitrosti izvajanja pa bi bila, hitrost pa je direktno odvisna od kvalitete implementacije konkretne CLR knjižnice in C# prevajalnika. Če hočeš imeti usodo v svojih rokah, potem pa napišeš:

 
 long l;
 
 b[0] = (byte)((l >> 56) & 0xff);
 b[1] = (byte)((l >> 48) & 0xff);
 .
 .
 .
 b[7] = (byte)(l & 0xff);
 

in v obratno smer:

 l = ((long)b[0] << 56) | ((long)b[1] << 48) | ... | ((long)b[6] << 8) | (long)b[7];
 

Če imaš uint, potem zamenjaš vse typecaste v uint, če imaš long, jih zamenjaš v long in tako naprej. Res pa je, da potem potrebuješ celoten traktat, ki sem ga napisal zgoraj, da pojasniš zakaj je to narejeno točno tako, kot je narejeno (*), in, zakaj je to najbolj optimalna verzija managed kode, ki jo lahko napišeš (klic v BitConverter je lahko potencialno še vedno hitrejši, če je CLR dobro implementiran - YMMW).

(*) Zato da se izogneš napaki prevajalnika, in, da ne dopustiš implicitno pretvorbo v več-biten tip.