Наверное это глупый вопрос и я подозреваю, что это сделать невозможно, но всеже:
Необходимо на этапе компиляции получить (и записать в константу) адрес битового поля, номер начального бита и количество бит, как это сделать?

минимально адресуемая ячейка это байт.
в константу врядли возможно записать адрес на этапе компиляции (возможность __asm { constdata equ $} врядли возможна..

можно по конкретнее с кусками кода...не уловил суть проблемы...

чтото типа такого, только чтоб работало. естевственно это работать не будет, а вообще возможно получить такие данные?

Можно. Напиши класс BitFieldPointer...

Адрес битового поля сможешь получить экспериментально. Выглядеть он будет в виде адреса байта+ смещение в байте. Смещение как раз и получишь экспериментально:разложи битовое поле на биты, заполни нолями и затем - единицами. Лучше пользуйся беззнаковыми целыми. Использовать этот адрес сможешь адрес + операция сдвига. 
И нахрена это ? Ведь битовое поле для того и предназначено, чтобы не было головной боли со сдвигами...

Зачем ставить эксперименты с положением бит? Их положение в байте строго определенное - бит 7 слева, бит 0 справа.

Это сообщение отредактировал(а) bsa - 16.7.2007, 21:49

Есть два варианта положений байт в слове: big endian (от старшего к младшему) и little endian (от младшего к старшему). На большинстве персональных компьютеров (x86) это little endian.

Ivan., я когда-то писал несколько макросов и вспомогательных классов для структур типа:

с тем, чтобы использовать их при составлении множества нужных мне параметров примерно таким образом:
DATA_BIT_ARRAY("x0",ss,s0,x0);
Все нужные мне параметры я вводил вручную (в тексте программы), в результате заполнялось множество
std::map<std::string, TypeVariant*> Data; 
Ну и, собственно, были определены методы Get и Set - получения и присваивания значений. Если тебя интересует это, то я на днях подготовлю тебе файлы с макросами и примером их использования

Это сообщение отредактировал(а) Ln78 - 17.7.2007, 09:46

Все это не то, мне нужно получить данные на этапе компеляции, а не во время работы программы.
Я согласен хотябы узнать только адрес начального байта битовой переменной.

Что ты понимаешь под данными? С помощью макросов как раз и получаются адрес целой переменной и маска, по которой находится то или иное битовое поле. И это всё, естественно, становится известно на этапе компиляции, я же просто заполняю исходный код такими макросами. Просто в той моей задаче эта информация использовалась, чтобы потом иметь возможность (уже в процессе выполнения задачи) получать или устанавливать нужные значения элементам структуры. Ведь и тебе эти данные нужны не просто так, ты же их потом как-то собираешься использовать?

Добавлено через 4 минуты и 6 секунд
Нет, я тебя обманул, вроде эти данные станут известны уже только в начале выполнения программы. Я уже точно не помню, относительно давно я этим занимался

Есть у меня подозрение, что ты где-то накосячил на этапе проектирования. Нет никакого смысла получать адрес на этапе компиляции, так как на этапе компиляции ты можешь напрямую обращаться к полям структуры тем самым получая доступ к данным.
Лучше объясни, зачем тебе это надо, и кто-нибудь скажет, как это правильно можно реализовать.

Первое, что я хочу уточнить: у меня процессор не X86, а микроконтроллер и по этому там особо не разгонишься. Мне нужно получить как можно больше информации еще на этапе компиляции, сформировать какую то структуру, чтобы потом быстро ее обрабатывать.
И так, задача у меня такая:
Нужно построить такую иерархию, каторая позволяла бы легко строить структурированное меню (меню отображения информации, настройки параметров и т.д.).
есть класс:
 
От этого класса потом плодятся подклассы типа TMenuVar, TMenuCombo, TMenuClock, TMenuPasword, TMenuBin, ...
А вся информация чем и как эти классы должны управлять и отображать находится в структуре TMenuProp.
Эта структура содержит такой вид:

Для каждого пункта меню мне нужно сформировать такую структуру и положить ее в область кода (потому что в оперативку, объемем в 4K, это все не влезет)
пример:

Естевственно есть макросы по заполнению этой структуры (объединение параметров, и т.д.)
Но когда вопрос встает об указании битового поля приходится брать чтото радом лежащее, говорить, что от этого адреса еще на пару байт вперед, там лежит от 4 бита на протяжении 3 бит переменная. Геморройно!
Вот я и хочу написать какой нибудь макрос, каторый би раскладывал бы это все по полочкам.

Что-то я опять не понял... А почему вариант с фигурными скобками тебя не устраивает? Или битовые поля инициализировать таким образом уже нельзя?

 непонял, где?

Я имел в виду это:

Ты имеешь в виду:

или зачем мне брать адрес битового поля?
в первом варианте закоментарено, потому что тяжко преобразовать указатель к битовому полю, а к инту легко (в Next я должен положить указатель следующего пункта меню). и вообще это структура параметров меню, а не структура, каторой управляет меню. мне не ее тяжело заполнить, а взять адрес переменной, каторой потом буду управлять.
Пример:
struct T{
        int A;
        unsigned int B:1;
} t;
const TMenuProp __Var1_Prop = { "Имя", "", "Информация", &Var2, &Var0, &t, (u16)&t.B - (u16)&t, startbit(T::B), sizeofbit(T::B), 0, 1, 1, 0 };
TMenuVar Var1(&__Var1_Prop);

есть такая задача:

приходит структура с битовыми полями
struct InStruct
{
  unsigned int a1:1;
  unsigned int a2:5;
  unsigned int a3:3;
  unsigned int a4:2;
  unsigned int a5:5;
  ...
  unsigned int an:1;
};

Структура потом идёт на обработку( от битовых полей строются графики, строятся таблицы и т.д. ),
причём пользователь может выбирать, например построение графиков от определённых полей.
Это приводит к тому, что адрес битового поля нужно передать как параметр в функцию.
Насколько мне известно, невозможно взять адрес битового поля.
Может кто-то подскажет правильное решение данной проблемы?

На ум приходит только создание парсера структуры, но как-то неправильно это, мне кажется.

А что делать(((

Я вижу два варианта "решения" проблемы:

1/  завести свою структуру с подобными полями, но без битов:

Затем тупо скопировать данные:
И оперировать дальше (для построения графиков и таблиц) своей структорой, в которой легко можно задать смещение нужного данного.
Недостаток метода - лишняя память и копирование данных.

2/ Создать подпрограмму по изъятию из структуры нужных данных:

И отправлять в функции построения таблиц и графиков нужную needed.
Недостаток метода - накладные расходы на case.

Иных выходов не вижу. Может, кто-то сумеет выйти через вход)))

ЗЫ Стоило создать новую тему...

Невозможно.


Передавай не адрес - а значение.

Это просто ужас. Вы пишете на C++, используете древовидное меню ( причем, дерево из списков ), и беспокоитесь о том, чтобы сэкономить память на использовании битовых полей?

Вы сэкономите намного ( в сотни раз, наверное ) больше, если откажетесь от этой навороченной архитектуры и сделаете простое статическое меню.

А насчет основного вопроса, опять же, статика - ваше спасение. Судя по началу топика, даже более, чем в каком либо другом случае. Вам не обязателен адрес поля, если вам нужны данные из него. Только адрес самой структуры и знание ее структуры) Значение любого битового поля с известным смещением и размером очень легко найти ( в универе этому не учили? )  <значение поля> = * <адрес структуры> & <значение равное по размеру структуре, с пустыми битами слева от поля и единицами в остальных битах> >> (<размер структуры> - <размер поля> - <к-во бит слева>)

например


Вот как-то так. Стоп. Я пропустил. А почему нельзя обратиться к полю как к полю, а не фигней страдать?
-------
А. Всё. Вижу. А зачем передавать адрес а не значение?


Это сообщение отредактировал(а) Fynivx - 20.1.2012, 17:39

Ээээ. Здесь так получилось, что 11Space11 использовал для нового вопроса старую тему(((
Его/её же вопрос здесь ;)

А... Извините) Но последний вопрос ( и он уже был озвучен до меня ) остается в силе - почему нужно передавать указатель, а не значение?

Не думаю, что именно указатель, может просто смещение. Просто есть набор однотипных данных, а пользователь может выбирать, по какому набору строить график или таблицу. Хочется реализовать это в функциях отрисовки однообразно: данные + смещение = значение. То есть, данные собираются в некоторую коллекцию, и именно эта коллекция передаётся функции отрисовки (сразу, целиком). Но что именно нужно отрисовывать из этих данных, определяется смещением ("адресом" конкретного битового поля в структуре данных). Получить значение, имея экземпляр структуры и смещение внутри этой структуры, быстро и элементарно для простых, небитовых полей. Для битовых полей это уже проблематично(((

Добавлено через 8 минут и 45 секунд
Кажется, я понял смысл Вашего вопроса))))

Можно ведь в фунцию отрисовки отправлять адрес подпрограммы, возвращающей нужное значение, типа:


Это очень хороший вариант решения)))

Я хочу только в одном месте цеплять структуру
, чтобы было легко менять.
что-то типа этого:






Структура содержит около 300 полей( и она не одна ). Получается:
Надо построить графики от данных - надо набирать 300*n строк( где n ~ 3 )
Надо построить таблицы от данных - опять надо набирать 300*n строк.
понадобится еще что - то - опять надо набирать 300*n строк.
Полный бред!

Но это не самое страшное. Структура постоянно меняется.  Если добавить новое поле все смещения надо будет рассчитывать заново.
И никогда не узнаешь правильно ли ты рассчитал все смещения. Надо все поля проверять.

Еще вариант - отказаться от битовых полей и использовать целочисленные поля с набором битов внутри такого поля (использовать битовую арифметику: & | << >> )

Не удобно.

Похоже придётся парсер препроцессором  делать.

Может кто-нибудь знает, что-нибудь готовое есть? 

озвутьте общую задачу, а то непонятно чего Вы хотите.. 

Чем Вам не понравился вариант с функциями, возвращаюшими желаемое значение из структуры, вместо адреса/смещения? То есть типа такого:


Собствеенно набор из 300 функций, таблицу функций, enum и другие описания можно генерить отдельной программой по описанию структуры InStruct.
Как то так...

и еще столько же сеттеров..

Точно!))) Правда, если структуру формирушь сам...

Я вот было подумал вначале, что структура чужая, данные берутся из чёрного ящика, и деваться некуда. Но:

Значит, всё-таки структура своя...