Отдельно не будет, а будет обнулено все содержимое класса, разом: memset(*class, 0, sizeof(class)). Сталкивался. Наступал на эти "грабли" (
Обход как выше прозвучал - через указатель на сами данные, которые инициализируем ручками и не даем обнулять через скрипты линкера и соотв. прагмы. Да костыль, но это точно работает.
Вот один из моих проектов, тут одна и та же плата, а на ней могут стоять разные камни.
Делаю под каждый камень свой проект. Исходники у них, разумеется, общие. А вот настройки проекта разные и есть особенности.
Ранее пытался делать это через target, но помучавшись с "особенностями" keil, перешел на такую схему разделения. Особенности отпали сами собой ))
В кеil так сделать нельзя, но можно обойти отчасти, отключая для каждого вручную "лишние" файлы. Это требует знания среды.
Но по опыту скажу, что лучше все же создать project workspace, а уже в него добавлять разные проекты для разных камней.
Внутри каждого проекта target разделять по иному принципу. Я разделяю их по типу DEBUG, RELEASE и др.
Переключение проектов в project workspace осуществляется кликом правой кнопкой мыши на нужным проектом "Set As Active Project".
Ядро среды сама по себе очень старое, поэтому такой странный и непривычный функционал ((
Написал же выше:
Я сам очень активно использую битовые поля внутри проекта, многие без передачи наружу. Очень помогает в читаемости кода.
На порядок удобнее, чем маски. А если использовать с union, то вообще сказка!
Компилятор хорошо понимает их и делает все правильно, не хуче, чем маски
В противном случае применение битовых полей вообще было бы невозможно.
Я активно применяю битовые поля, проблем не было, кроме выравнивания, когда забывал в нужных местах добавить прагму.
Да. Поэтому если данные передаются в каком-то виде наружу, то прамга нужна. Если нет - то не обязательно.
Расположение битов внутри как раз регламентировано: сверху младшие, внизу старшие (для little endian). Тут переживать не стоит.
Другое дело, что если эти данные нужно передавать наружу по какому-нить послед. протоколу, то без упаковки могут быть проблемы на принимающей стороне - развалится структура пакета.
Поэтому я добавляют в таких случаях assert (sizeof(...) == ...). Так хотя бы компилятор заругается, если что.
Внутри struct биты будут расположены вплотную, как описано и в указанном порядке, но без #pragma попытка прямого обращения к байту, где хранятся этим поля, действительно непредсказуемо. Если проц 32-х битный, то без нужной прагмы будет создано 32-битное слово для этих 8ми бит.
Достаточно обрамить ваш код такой конструкцией (GCC) и весь union станет строго 8-битным:
#pragma pack(push, 1)
.....
#pragma pack(pop)
На будущее по личному опыту - НИКОГДА не размещайте личные файлы, проекты и т.п. на системном диске ))
На системных дисках я размещаю только систему и установленные программы.
Под виндой на рабочем столе также НИКОГДА не размещайте файлы личного содержания и т.п. Только ярлыки.
В этом случае при любом сбое системы вы ничего важного не потеряете.
Для вас "шашечки", а для меня - необходимость. Не все способны держать в голове чудовищную кашу и запутанной структуры проекта и горы мудреных макросов ради макросов. Я так не умею. Не расстроен ни разу.
И мне глубоко плевать на немного бОльший расход озу - камни у меня в проектах всегда имеют многократный запас по ресурсам. Впроголодь не живем, как некоторые :)
Читаемость кода на первом месте для меня. К тому же вызов через делегат позволяет избежать вложенного вызова цепочки методов, как этого приходилось делать раньше.
Более структурирование построение кода позволяет упростить код там, где это было невозможно сделать нормально. Количество багов и детских граблей заметно сократилось. Код по сути становится быстрее, что некоторым покажется парадоксально.
Опять-таки, нравится вам сидеть на голых сях и макросах - дело ваше. Но для меня это - пройденный этап, обратно не вернусь, хватит, намучался.
При особо богатой фантазии можно и не такое увидеть :)
Желтым цветом выделена команда, адрес которой вписан в таблицу векторов в соотв. месте. Т.е. это - первая команда, которая вызывается при входе в конкретно взятый обработчик.
Последняя 4я - это безусловный переход на сам метод, адрес которого забит в этот делегат.
Ничего подобного ))
Вот вызов делегата с момента входа в обработчик, BX - это уже вызов конкретно user-обработчика, который повешен на делегат (метод-класса):
В r0 записывается соотв. this владельца этого user-метода. В r1 - адрес этого user-метода. Это по сути вызов c++ метода класса. Оптимизация конечно включена. Компилятор конечно v6. Справляется на ура )
