jenya7 0 19 января, 2017 Опубликовано 19 января, 2017 · Жалоба Сделал такую проверку. typedef struct MY_STRUCT_S { uint8_t b1; uint8_t b2; uint8_t b3; uint8_t b4; }MY_STRUCT; MY_STRUCT struct1; uint32_t n = sizeof(struct1); n = 4. Без #pragma pack. Кто кого обманывает? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gosha-z 2 19 января, 2017 Опубликовано 19 января, 2017 · Жалоба А теперь то же самое со структурой struct blablabla { uint8_t a; uint16_t b; }; Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jorikdima 0 19 января, 2017 Опубликовано 19 января, 2017 · Жалоба Что не так? Почитайте про структуры. Полно же материалов в сети. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 119 19 января, 2017 Опубликовано 19 января, 2017 · Жалоба n = 4. Без #pragma pack. Кто кого обманывает? А сколько надо? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 19 января, 2017 Опубликовано 19 января, 2017 · Жалоба А вообще, зачем Вам надо знать размер структуры, и, насколько я предполагаю, с точностью до байта, да еще и в контексте #pragma pack(x) ? Вам жалко компилятор, и Вы хотите ему помогать ? :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
megajohn 3 19 января, 2017 Опубликовано 19 января, 2017 · Жалоба Кто кого обманывает? вот даже курсы на халяву есть. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jenya7 0 19 января, 2017 Опубликовано 19 января, 2017 · Жалоба А вообще, зачем Вам надо знать размер структуры, и, насколько я предполагаю, с точностью до байта, да еще и в контексте #pragma pack(x) ? Вам жалко компилятор, и Вы хотите ему помогать ? :) до сих пор я все поля делал uint32_t хотя у меня есть члены структуры для которых uint8_t достаточно. у меня есть довольно большая структура и есть массив этой структуы который отжирает много места в RAM. если я перейду с uint32_t на uint8_t я сэкономлю много места. но тогда компайлер будет выполнять операции boxing/unboxing? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Kabdim 0 19 января, 2017 Опубликовано 19 января, 2017 · Жалоба Всем же известно что если значения инт помещаются в диапазон -128 ... 127 то boxing/unboxing будет соптимизирован. :] Как там написано объект lnteger может занимать до 12 байт. Занимательная ява А если серьезно, то http://bfy.tw/9Z3Y . :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jenya7 0 19 января, 2017 Опубликовано 19 января, 2017 (изменено) · Жалоба Всем же известно что если значения инт помещаются в диапазон -128 ... 127 то boxing/unboxing будет соптимизирован. :] Как там написано объект lnteger может занимать до 12 байт. Занимательная ява А если серьезно, то http://bfy.tw/9Z3Y . :) а кто сказал что перед ldrb не будет произведен boxing/unboxing? а...понял - Zero extend to 32 bits on loads. то еть можно спать спокойно? Изменено 19 января, 2017 пользователем Jenya7 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
esaulenka 5 19 января, 2017 Опубликовано 19 января, 2017 · Жалоба до сих пор я все поля делал uint32_t хотя у меня есть члены структуры для которых uint8_t достаточно. у меня есть довольно большая структура и есть массив этой структуы который отжирает много места в RAM. если я перейду с uint32_t на uint8_t я сэкономлю много места. но тогда компайлер будет выполнять операции boxing/unboxing? Действительно, как же компайлер (Herz! где же Herz?! :-) ) будет их выполнять?.. Он же компайлер языка си, слова боксинг не разумеет... What is Boxing and Unboxing? Conversion of a primitive type to the corresponding reference type is called boxing, such as an int to a java.lang.Integer. Conversion of the reference type to the corresponding primitive type is called unboxing, such as Byte to byte. Since JDK 1.5, Conversion from primitive types to corresponding wrapper objects and vice versa can happen automatically. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 19 января, 2017 Опубликовано 19 января, 2017 · Жалоба до сих пор я все поля делал uint32_t хотя у меня есть члены структуры для которых uint8_t достаточно. у меня есть довольно большая структура и есть массив этой структуы который отжирает много места в RAM. если я перейду с uint32_t на uint8_t я сэкономлю много места. но тогда компайлер будет выполнять операции boxing/unboxing? Я решаю аналогичную задачу (запись архива событий, записи различных форматов и различной длины). Чтобы не делать запись всегда из максимально-используемой длины, используя "замес" из структур типов-форматов-ABC в структуре, объединенных union { char[30] или str_A или str_B или str_C или . . . . ) ABC определены как типы. Как вариант, можно ваш супер-массив преобразовать в массив указателей на массивы структур, или их элементы, каждый из которых будет содержаться в "своем", оптимизированном под нее по размеру. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jenya7 0 19 января, 2017 Опубликовано 19 января, 2017 · Жалоба Я решаю аналогичную задачу (запись архива событий, записи различных форматов и различной длины). Чтобы не делать запись всегда из максимально-используемой длины, используя "замес" из структур типов-форматов-ABC в структуре, объединенных union { char[30] или str_A или str_B или str_C или . . . . ) ABC определены как типы. Как вариант, можно ваш супер-массив преобразовать в массив указателей на массивы структур, или их элементы, каждый из которых будет содержаться в "своем", оптимизированном под нее по размеру. да я просто заменю uint32_t на uint8_t. в любом случае влияние на скорость исполнения будет небольшое по сравнению с сэкономленым местом в RAM. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться