Forum » Programiranje » [C#] int to byte[]
[C#] int to byte[]
alum ::
Zdravo, sestavljam paketek (byte array) za pošiljanje po omrežju.
Znotraj tega paketka je tudi 7 mestna številka. Ta je shranjena v v 4 bajtih. Vendar če jo pretvorim v string(char[]) in nato v byte[] s pomočjo System.Text.ASCIIEncoding classa zavzame ta 'številka' 7 bytov (torej število cifer).
Obstaja kaka enostavna pot, da bi int32 zakodiral v byte[] in kasneje odkodiral?
Lp.
Znotraj tega paketka je tudi 7 mestna številka. Ta je shranjena v v 4 bajtih. Vendar če jo pretvorim v string(char[]) in nato v byte[] s pomočjo System.Text.ASCIIEncoding classa zavzame ta 'številka' 7 bytov (torej število cifer).
Obstaja kaka enostavna pot, da bi int32 zakodiral v byte[] in kasneje odkodiral?
Lp.
alum ::
Ponavadi najdem rešitev takoj za tem, ko vprašam.
System.BitConverter class je rešitev, če bo zanimalo še koga.
[aja gre za .NET Framework 1.1]
System.BitConverter class je rešitev, če bo zanimalo še koga.
[aja gre za .NET Framework 1.1]
Mmm'Aah ::
freakin managed C# sh*t....
v c-ju se to kar si hotu nardit doseze preprosto tako da castas naslov int32 spremenljivke v pointer na byte;
int a = 1234567;
char *b = &a;
thats all.
v c-ju se to kar si hotu nardit doseze preprosto tako da castas naslov int32 spremenljivke v pointer na byte;
int a = 1234567;
char *b = &a;
thats all.
Rapsey ::
freakin managed C# sh*t....
Uporabil bom smiley ki ga preziram, ampak je zelo primeren trenutno:
Mmm'Aah ::
no da ne bo moj post samo grd off-topic naj dodam se poanto:
Isto kot v Cju lahko dosezes tudi v C# ce z nekim ukazom (ali pre-processorkim ukazom) vklopis dovoljenje za unmanaged nacin, ampak sem pozabil tocno kako se to nardi. V tvojem primeru ko se igras z byte-i bi blo to mogoce zelo primerno.
Sicer, pa... ja, managed koda ju hudo vredu za programerje ki ne znajo sami pisat safe kode, ker se s tem avtomatsko zavarujes buffer overflow nevarnosti in memory leak napakam... dolocene stvari pa se nardi dosti hitreje in bolj ucinkovito z neposrednim dostopom do naslovov spremenljivk.
Isto kot v Cju lahko dosezes tudi v C# ce z nekim ukazom (ali pre-processorkim ukazom) vklopis dovoljenje za unmanaged nacin, ampak sem pozabil tocno kako se to nardi. V tvojem primeru ko se igras z byte-i bi blo to mogoce zelo primerno.
Sicer, pa... ja, managed koda ju hudo vredu za programerje ki ne znajo sami pisat safe kode, ker se s tem avtomatsko zavarujes buffer overflow nevarnosti in memory leak napakam... dolocene stvari pa se nardi dosti hitreje in bolj ucinkovito z neposrednim dostopom do naslovov spremenljivk.
BlueRunner ::
ON TOPIC:
Stikalo, ki ga iščeš, je "/unsafe". Ime že lepo pove, da je dobro vedeti, kaj potem programer v kodi počne.
OFF TOPIC:
Hm, ja... in potem dobiš hordo VB/Java/VB.Net/C# kvazi programerjev. In to takšnih, ki ti pokažejo resničen pomen izrazov memory leak, resource leak in integer overflow. Pri takšnih primerkih se vedno spomnim na večen stavek: "Unsafe at any language."
Osebno pa mislim, da je za vsakogar, ki si želi reči programer, nujno poznavanje delovanja računalnika in platforme, ki jo uporablja. Neznanje pa je izredno dober signal, da pred seboj nimaš programerja, temveč nekaj drugega (morda sistemskega arhitekta, da ne bo kdo rekel, da sem žaljiv). VM okolja so iz vidika učinkovitosti dela dokaj prijetna za uporabo, saj je danes vse manj težav, kjer bi bilo potrebno iz razpoložljivih virov iztisniti čim več za vsako ceno. V konkretnem primeru sicer ni konteksta, vendar pa bi se le stežka odrekel VM okolju, kjer mi je potrebno pisati manj "housekeeping" kode za, samo zaradi nekaj "nenaravnih" pretvorb. Produktivnost tukaj pač vedno odtehta tistih nekaj 0.1s, ki bi jih prihranil z ne-VM okoljem. Če pa nek netrivialen del aplikacije v določenem okolju zahteva ogromno virov samo zaradi lastnosti VM okolja (boxing, unboxing), pa zagotovo ne bi izbral VM okolja, saj bi to bil dober znak, da problema sploh ne znam pravilno ovrednotiti.
Kot vedno je najboljše "kladivo" predvsem velik zaboj "kladiv", kjer je vsako odlično za nekaj, največja umetnost pa je najti pravo kombinacijo za izziv, ki je pred menoj.
Stikalo, ki ga iščeš, je "/unsafe". Ime že lepo pove, da je dobro vedeti, kaj potem programer v kodi počne.
OFF TOPIC:
Hm, ja... in potem dobiš hordo VB/Java/VB.Net/C# kvazi programerjev. In to takšnih, ki ti pokažejo resničen pomen izrazov memory leak, resource leak in integer overflow. Pri takšnih primerkih se vedno spomnim na večen stavek: "Unsafe at any language."
Osebno pa mislim, da je za vsakogar, ki si želi reči programer, nujno poznavanje delovanja računalnika in platforme, ki jo uporablja. Neznanje pa je izredno dober signal, da pred seboj nimaš programerja, temveč nekaj drugega (morda sistemskega arhitekta, da ne bo kdo rekel, da sem žaljiv). VM okolja so iz vidika učinkovitosti dela dokaj prijetna za uporabo, saj je danes vse manj težav, kjer bi bilo potrebno iz razpoložljivih virov iztisniti čim več za vsako ceno. V konkretnem primeru sicer ni konteksta, vendar pa bi se le stežka odrekel VM okolju, kjer mi je potrebno pisati manj "housekeeping" kode za, samo zaradi nekaj "nenaravnih" pretvorb. Produktivnost tukaj pač vedno odtehta tistih nekaj 0.1s, ki bi jih prihranil z ne-VM okoljem. Če pa nek netrivialen del aplikacije v določenem okolju zahteva ogromno virov samo zaradi lastnosti VM okolja (boxing, unboxing), pa zagotovo ne bi izbral VM okolja, saj bi to bil dober znak, da problema sploh ne znam pravilno ovrednotiti.
Kot vedno je najboljše "kladivo" predvsem velik zaboj "kladiv", kjer je vsako odlično za nekaj, največja umetnost pa je najti pravo kombinacijo za izziv, ki je pred menoj.
darkolord ::
Hm, kaj je pri BitConverter.GetBytes() tako kompliciranega, upoštevajoč to, da je ta metoda safe?
Rapsey ::
Hm, kaj je pri BitConverter.GetBytes() tako kompliciranega, upoštevajoč to, da je ta metoda safe?
Čisto nič. Mmm'Aah in BlueRunner kr bluzita o nečem tretjem, ki nima veze.
alum ::
Managed način je veliko preglednejši in transparantnejši.
byte[] b = BitConverter.GetBytes(1234567)
vs.
int a = 1234567;
char *b = &a;
Ali pa se morda komu spodnje zdi lažje razumljivo za razvijalca, ki dobo kodo v vzdrževanje?
byte[] b = BitConverter.GetBytes(1234567)
vs.
int a = 1234567;
char *b = &a;
Ali pa se morda komu spodnje zdi lažje razumljivo za razvijalca, ki dobo kodo v vzdrževanje?
sid_dabster ::
@BlueRunner:
Se podpisem pod tvoj post!
Se podpisem pod tvoj post!
Fallen beyond all grace deeper and deeper
The sound of her own blood dripping
Like sacred tears from a bleeding rose...( Embraced, Within)
The sound of her own blood dripping
Like sacred tears from a bleeding rose...( Embraced, Within)
CCfly ::
Ocenjevanje kladiv naj se prosim preseli v drugo temo.
"My goodness, we forgot generics!" -- Danny Kalev
Vredno ogleda ...
| Tema | Ogledi | Zadnje sporočilo | |
|---|---|---|---|
| Tema | Ogledi | Zadnje sporočilo | |
| » | Web services - Neveljavni karakterji v XMLOddelek: Programiranje | 4131 (3243) | boolsheat |
| » | [JAVA] HTTPS clientOddelek: Programiranje | 3175 (1905) | peterv6i |
| » | Program v C - nujnoOddelek: Programiranje | 1952 (1627) | Ktj |
| » | [C#] int v byte[] in nazajOddelek: Programiranje | 1801 (1573) | BlueRunner |
| » | branje byte[] iz MS access-ove bazeOddelek: Programiranje | 1936 (1846) | BHawk |