Revision history [back]
 | 1 | initial version | posted 2015-02-21 13:19:25 +0100  |
Ano, ale musíte si to pohlídat:
- Velikost některých datových typů se může na různých platformách lišit (např.
intbýval původně 16bitový). Takže je potřeba použít takové datové typy, které mají velikost konstantní bez ohledu na platformu. - Je třeba vyřešit alignment jednotlivých elementů struktury. Problém je, že to je různé pro různé kompilátory (např.
#pragma packpro MSVC), a navíc některé platformy nemusí některá zarovnání vůbec podporovat (jestli si dobře vzpomínám, tak zejména RISCové architektury jsou na to náchylné). Ale ano, mělo by to jít vyřešit dost univerzálně.
Kromě toho samozřejmě můžete říct, "můj program je určený pro 32bitová Windows, jiné platformy mě nezajímají a 64bitovou verzi taky kompilovat nebudu" a zarovnání vyřešit na úrovni system requirements :-)
| | 2 | No.2 Revision |
Ano, ale musíte si to pohlídat:
- Velikost některých datových typů se může na různých platformách lišit (např.
intbýval původně 16bitový). Takže je potřeba použít takové datové typy, které mají velikost konstantní bez ohledu na platformu. - Je třeba vyřešit alignment jednotlivých elementů struktury. Problém je, že to je různé pro různé kompilátory (např.
#pragma packpro MSVC), a navíc některé platformy nemusí některá zarovnání vůbec podporovat (jestli si dobře vzpomínám, tak zejména RISCové architektury jsou na to náchylné). Ale ano, mělo by to jít vyřešit dost univerzálně.
Kromě toho samozřejmě můžete říct, "můj program je určený pro 32bitová Windows, jiné platformy mě nezajímají a 64bitovou verzi taky kompilovat nebudu" a zarovnání vyřešit na úrovni system requirements :-)
Ještě doplním jednu věc - u načítání dat tímto způsobem je potřeba hlídat i další věci, ne jen alignment. Podstatná je třeba endianness procesoru (když budu načítat 0x01, 0x02, 0x03, 0x04 jako 32bitový integer, tak mi to dá dost podstatně jiný výsledek na LSB i386 a na MSB 68000), reprezentace datových typů (nemusí všichni používat stejný formát desetinného čísla, nemusí všichni používat ASCII nebo Unicode) atd. atd. Blo by čistší načíst si jeden binární blok a ten potom po bajtech rozebrat a zkonvertovat do podoby vhodné pro tu moji aktuálně používanou platformu. Ale málokdo to dělá, protože to je hodně práce a vesměs to nestojí za to - "když si to někdo bude chtít spustit na 16bitové Motorole, tak si tuhle část přepíše, proč bych to měl dělat já".
| | 3 | No.3 Revision |
Ano, ale musíte si to pohlídat:
- Velikost některých datových typů se může na různých platformách lišit (např.
intbýval původně 16bitový). Takže je potřeba použít takové datové typy, které mají velikost konstantní bez ohledu na platformu. - Je třeba vyřešit alignment jednotlivých elementů struktury. Problém je, že to je různé pro různé kompilátory (např.
#pragma packpro MSVC), a navíc některé platformy nemusí některá zarovnání vůbec podporovat (jestli si dobře vzpomínám, tak zejména RISCové architektury jsou na to náchylné). Ale ano, mělo by to jít vyřešit dost univerzálně.
Kromě toho samozřejmě můžete říct, "můj program je určený pro 32bitová Windows, jiné platformy mě nezajímají a 64bitovou verzi taky kompilovat nebudu" a zarovnání vyřešit na úrovni system requirements :-)
Ještě doplním jednu věc - u načítání dat tímto způsobem je potřeba hlídat i další věci, ne jen alignment. Podstatná je třeba endianness procesoru (když budu načítat 0x01, 0x02, 0x03, 0x04 jako 32bitový integer, tak mi to dá dost podstatně jiný výsledek na LSB i386 a na MSB 68000), reprezentace datových typů (nemusí všichni používat stejný formát desetinného čísla, nemusí všichni používat ASCII nebo Unicode) atd. atd. Blo Bylo by čistší načíst si jeden binární blok a ten potom po bajtech rozebrat a zkonvertovat do podoby vhodné pro tu moji aktuálně používanou platformu. Ale málokdo to dělá, protože to je hodně práce a vesměs to nestojí za to - "když si to někdo bude chtít spustit na 16bitové Motorole, tak si tuhle část přepíše, proč bych to měl dělat já".
