преобразование типов №2 0

Artur
unsigned char ch[4];

*(unsigned long*)(&ch) = 0xAD;

что этот фрагмент может значить??

и почему именно так??

Пример неумного выпендривания. Дядя решил присвоить значения всему массиву сразу. Сейчас в ch[3] находится байт 10101101, а в остальных трех элементах массива ch[] находятся нули.

Неумно, потому что подразумевает sizeof(char) = 1, sizeof(long) = 4, что, конечно верно для 8×86, но может быть неверно для других архитектур. И читать эту галиматью сложно, как ты уже убедился. Не делай так.

Good Luck,

UT

ИМХО если уж припёрло, то лучше так:

union U {
  unsigned char c[sizeof(long)];
  unsigned long l;
};
U u;
u.l = 0xAD;

ИМХО если уж припёрло, то лучше так:

и, что не маловажно, сделать

#pragma pack(1);

во избежание.

факт

Uncle Theodore
Дядя решил присвоить значения всему массиву сразу. Сейчас в ch[3] находится байт 10101101, а в остальных трех элементах массива ch[] находятся нули.

а вот и неправильно ;) Память бывает по разному организована, может быть что ch[3]==0xad, а может оказаться что и ch[0]==0xad. И, замечу, x86 использует второй способ, он ещё называеться big-endian — младший байт по младшему адресу. А про первый вариант (little-endian), я только слышал, и знать не знаю на хрена такие сложности нужны.

Надо смотреть на контекст, чтобы понять зачем он это делает (может просто проверяет endianess машины)

Да, согласен, на x86 будет ch[0]==0xad

Только и ты ошибся — младший байт по младшему адресу называется little-endian, каковым и является x86,,, :-)

http://en.wikipedia.org/wiki/Endianness

Good Luck,

UT

действительно…

На самом деле big-endian не сложности, а естественное положение вещей. ИМХО. Т.е. это интуитивно понятное человеку явление. А вот little-endian было введено Intel потому, что раз биты в байте нумеруются справа налево, то и байты в слове должны так же располагаться.

может быть. но когда мозги свёрнуты x86 ассемлером, сложно себе представить как бороться с проблемами little-endian.