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

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

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

или зачем мне брать адрес битового поля?
в первом варианте закоментарено, потому что тяжко преобразовать указатель к битовому полю, а к инту легко (в 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.
Как то так...