Структура числа int в памяти

Как у тебя бит равняется числу? Наркоман?

Может, хватит употреблять такие вещества?

ман битовые операции. у меня первым результатом в гугле на твой переформулированый вопрос это: http://www.dzone.com/snippets/print-binary-number-c

char *mem = (char*) &i; mem[0], mem[1], mem[2], mem[3] содержат первые 4 байта представления числа i.

Вопрос есть к знатокам: такая конструкция корректно порядок байт для BE/LE покажет?

1 бит = 0x24

Ты бит с байтом перепутал? o_O

Да, конечно, почему нет?

Кстати, union-ы лучше, чем приведение типов указателей (gcc с -O2 может и нули показать в более сложных случаях, man strict aliasing).

char* может алиасить всё что угодно.

Да? Ну может и так, я на всякий случай упомянул :)

Спасибо!

Читал просто как-то про union и геморой с выравниваниями. Вот с тех пор (uchar *) и пользую... Решил спросить - может у кого опыт применения в реальной жизни есть.

геморой с выравниваниями

читай про структуры, там выравнивание тоже самое.

Да, вроде как если платформа такая злобная, что адресовать умеет только по 4-хбайтной границе, только сдвиганием в явном виде можно получить куски. Но так не узнаешь, что там реально в памяти в каком порядке.

тебе что нужно?

если знать как байты (2ух или четырёх или восьмибайтного инта хранятся ) то присваиваеш в нулевой области (на 256) уникальные байты а потом по известному адрессу читаеш как инт и смотриш что за число прочиталось из этого понятно станет младшие впереди , старшие впереди , или как в сфэйлившем по этому 32битном pdp11(который был биг эндиан на 16битах и убейся об стену от произвола и сиюминутного решения на 32 битах) или вообще перестановка 8 элиментов(их как раз 8!) - вдуг у этого конкретного имбедеда так НУЖНО.

по анси вроде гарантируется тока непрерывность памяти которая достаточна для хранения 2в 16 различных состояний хоть гигабайт на инт и битики размазаны в художественном беспорядке.

Все наоборот. PDP-11 хранит байты в слове в LE-порядке, а две с половиной 32-разрядных инструкции обращаются к словам внутри двойного слова как BE.

ок . фишка про которую считаю важно помнить и знать что нашлись идиоты и/или практическая необходимость скрестить 2 разных направления размещения старшей и младшей половины при разбещении 4 байт.

и всё таки pdp11 вроде старший байт слова хранил по меньшему адресу

короче если 4 байта в арабской записи по основанию 256 записать как x01x02x03x04 то в памяти оно лежало как (x02x01x04x03 либо x03x04x01x02) в отличии от чистого младшие вперёд(BE?) (x04x03x02x01) и чистого старшие раньше(x01x02x03x04)

LE -это младшая часть имеет больший адресс?

так как x86 хранит слово как меньший адресс -младший байт поэтому и называется LE

ок в результате
int a[2]={1,0}
*((long*)(a+0)) умножает на 256 что печально ибо тоже самое с char2int не катит.

Да, вроде как если платформа такая злобная, что адресовать умеет только по 4-хбайтной границе

это какая такая платформа?

он вроде про arm

#include <stdio.h>

unsigned char get_byte(int x, unsigned char n)
{
    return ((unsigned int)x >> (n << 3)) & 0xff;
}

int main(void)
{
    int i = 2780;

    for (int b = 0; b < 4; ++b)
        printf("%dB = %d\n", b, ((unsigned char*)&i)[b]);

    for (int b = 0; b < 4; ++b)
        printf("%dB = %d\n", b, get_byte(i, b));

    return 0;
}

$ ./a.out
0B = 220
1B = 10
2B = 0
3B = 0
0B = 220
1B = 10
2B = 0
3B = 0

220 * (2 ^ 8) ^ 0 + 10 * (2 ^ 8) ^ 1 + 0 * (2 ^ 8) ^ 2 + 0 * (2 ^ 8) ^ 3 == 2780

Гуглить нужно словосочетание «get bit/byte from integer».

sizeof(char) по стандарту 1, sizeof от массива размера N N*sizeof от элемента, так что это уже проблемы компилятора, как он будет доставать тебе байт, пусть сдвиги вставляет.

В arm нельзя читать невыровненное четырёхбайтное значение (на самом деле и в x86, хоть формально и можно, но лучше не надо), а байт можно считать по любому адресу.

uint8_t же. Существует ненулевая вероятность, что char занимает не один байт.

Существует ненулевая вероятность, что char занимает не один байт.

можно CHAR_BIT проверить

LE @ BE во все поля

uint8_t же. Существует ненулевая вероятность, что char занимает не один байт.

В языке С/С++ не существует.

В языке С/С++ не существует.

существуют архитектуры способные адресовать только слово.

и всё таки pdp11 вроде старший байт слова хранил по меньшему адресу

Доки почитай, норкоман.

вики оказалось достаточно.

в любом случае финт ушами в разнонаправленности порядка байт в слове и слов в двойном - очень дорогая ошибка дизайна.

Чем же она такая дорогая?

хз. ненужная сложность.

Вопрос есть к знатокам: такая конструкция корректно порядок байт для BE/LE покажет?

да, конечно. Тут две переменные в одной и той же памяти.

ЗЫЖ за использование таких конструкций в продакшене бьют канделябрами по голове. А посмотреть - посмотри...

Читал просто как-то про union и геморой с выравниваниями.

в моём примере никакого гемора не будет, инфа 146%.

Существует ненулевая вероятность, что char занимает не один байт.

число бит в байте не играет роли. Union будет работать, даже если в байте 6 или 66 бит. Дело в том, что sizeof(char) === 1 по определению. При этом, sizeof(int) указывает длину int в char'ах, если в int 100 бит, а в char 66 бит, то sizeof(int) == 2. И моя структура будет работать правильно. Как компилятор будет доставать 66и битные char'ы - его проблемы, но дырок между ними НЕ будет, потому union будет выдавать то, что есть.

существуют архитектуры способные адресовать только слово.

это проблема компилятора. Либо в нём word === char, либо пусть двигает слова, доставая char'ы andом.

...в продакшене бьют канделябрами по голове.

Повеселило ;-)

Ведь на самом деле, битмаски + сдвиг рулят, универсальны и компиляторонезависимы.

бит с байтом - да перепутал, спасибо за достоиные ответы.

улыбнуло)

Иногда во время чтения лоровского /d/, у меня складывается впечатление, что это норкоманы барыжат веществами, обмениваясь стеганографическими сообщениями..

ну ты поднялся