4 bájton tárolt számból hogy lehet kinyerni a számot alkotó bájtok értékeit? (bővebben lent)

"Ehhez meg szükséges a byte sorrend ismerete."

Természetesen a visszaalakításnál nem közömbös a sorrend.

Én a #12-es válaszra írtam hogy mindegy a sorrend.

Az a válasz a szétszedésről szólt ha jól értettem.

Szia.

Szerintem, ahogy már valaki irta, mozgasd, át egy 4 bájtból álló tömbbe a "move" parancsal, ez visszafelé is müködik, tehát a 4 bájtból álló tömbböt vissza tudod mozgatni a megadott változóba.

Egyébként az sem mindegy, hogy hogy milyen tipusú az a 4 bájtból álló változó:

Longint / longword : -2147483648..2147483647 / 0..4294967295

Single : 1.18e-38 .. 3.40e+38

Longint-ben a 1457664 érték : 0 62 22 0

Single-ben a 1457664 érték : 0 240 177 73

Sok sikert.Üdv.

"Amúgy egy négy darabos halmaz az eredmény. Bájtok halmaza."

Az nem halmaz. A halmazban nem lehet két egyforma elem és a sorrend nem számít : [link]

A move hardverspecifikus. Egyébként szintén hardverfüggően pointeraritmetikával is működik. Egy byte pointert rámutatni longint változóra és a byte pointert lehet tömbként indexelni, maga a longint lesz byte tömbnek tekintve, de ha nem érdekli a kérdezőt akkor nem érdekli. Ha lesz 1 valaki is akit érdekel akkor neki szól.

"Az nem halmaz. A halmazban nem lehet két egyforma elem"

LOL

"Mindenfajta megoldás érdekel, nagyon jó új ismereteket szerezni."

Ezt jó látni, mert nem ez a jellemző.

Amiről beszéltem : [link]

Itt az "a" változó byte típusú pointer, ha úgy tetszik egy tömb. Ha akarom az "a" változón keresztül tömbként kezelem, ha azt akarom akkor pedig longint-ként kezelem ugyanazt a memória területet. A példában x:=-1; majd a[0]-át íratom ki, a -1 érték 255-re változtatja minden bájtját, így a[0] is más lesz mint volt, mindegy milyen a bájtsorrend ezért ezt írtam a példában.

Tömböt 0-tól indexelünk úgy általában (ezt nem nyelvspecifikusan mondom). Igaz nagyon régen amikor még pascalt tanították nekem akkor 1-től indexelte a tanár a tömböket, meg pascalban jellemző 1-től ha tömböt deklarálunk. Visszatérve itt 0-tól 3-ig indexelendő az "a". Nem javaslom, inkább érdekességképpen említem meg, hogy egy a -= 1;-val 1-től 4-ig indexelendővé tehetem, a pointeraritmaitika miatt működik. A háttérbe a "színfalak" mögött egyébként is mindig pointeraritmaitika van tömbök esetében.

Eltérő bájtsorrenddel rendelkező hardverek esetén lévő bináris számokat tartalmazó hálózati forgalom, fájlcsere esetében van jelentősége hardverfüggetlen implementációról beszélni, de akkor tisztázni kell, hogy melyik bájtsorrendről van szó, hogy egységesen működjön.

24-27: Talán túl sok hülyeséget tolsz.

Tömbök esetében egyáltalán nem biztos, hogy pointer-aritmetika húzódik meg a háttérben. Már ami a tömbelemek elérhetőségét illeti.

Na és pascalban kivételesen szabad az indexelhetőség, tehát egy tömböt indexelhetek éppen hattól is, ha nekem az úgy tetszik. Azt, hogy a tanárod volt olyan f.sz, hogy egynek vette az alsó indexhatárt, hát azt meg talán nem itt kéne hirdetni.

Halmazelméleti bölcselkedéseidet is nyugodtan megtarthatod magadnak, én legalábbis, köszi, de nem kérek belőle.

Az endiannessel megfűszerezett hálózati forgalomról szóló egypercesed is megérne ugyan egy misét, de abba inkább már nem állok bele.

Még egy megjegyzés a tömbök és a pointerek kapcsolatához.

A pascal nyelv nyelvi szinten támogatja hogy egy tömb indextartománya például 10-től 20-ig legyen, például t : array[10..20] of word; . Elvonatkoztatva a pascalos tankönyvektől, pascal oktatástól az a megszokott hogy 0-tól indexeljük a tömböket.

Egy példa ahol dekraláltam egy a fentebbi "t" tömböt, "p_w" egy word típusú pointert pedig tömbként használtam a "t" tömb memóraterületén. Látszik hogy egyik esetben 0-tól 10-ig, másik esetben pedig 10-től 20-ig indexelt, amikor valójában ugyanazon memóraterület két külön fajta elérése és tömbként indexelése.

[link]

Ugyanezt az eredményt adja, ha csak a for ciklus értékadását látjuk, hogy a p_w az pointer típusú változó amikor a tömböt feltölti : [link]

"Hardver-függő és független megoldás alatt mit kell érteni pontosan?"

Ha hardverfüggő akkor a megoldás eredménye függ a hardver architektúrájától (illetve ha több fajta endianness-t is támogat az adott hardver akkor pedig attól függ, hogy a free pascal compiler milyen bináris futtathatót állított elő az adott hardverre).

Ha hardverfüggetlen akkor pedig a számítás menete nem függ attól hogy milyen a hardver architektórája, ugyan azt fogjuk kapni. Viszont ez esetben (legalábbis triviálisan) nincs meg az a hardveres gyorsítás hozzá mint a hardverfüggő esetben.

"Free Pascal-t különféle architektúrákon futtatva egyes konverziók "más-más eredményt adhatnak"?"

Ez esetben akár amit én mutattam be akár a move esetében nincs konverzió. A move nyersen memóraterületet másol át (nem tudja hogy milyen adatokokat reprezentál), ha nem lenne ez a beépített procedure (de így se akadály hogy már van) könnyen lehetne írni egy ilyen procedure-t. Amit én mutattam be a longint-ra ott még memóraterület másolás sincs. Itt annyiról van szó, hogy az adott memóriaterület minek tekintjük és minek kezeljük hogy mi az. A háttérbe nyers bájtok vannak mindig.