Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Не получается разместить в структуре неполный (Incomplete) массив
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > AVR
Alechin
Работаю в IAR 4.10A
По хелпу последним элементом структуры может быть незавершенный массив - вот как ее (структуру) объявляют в мануале на компилятор:
struct str
{
char a;
unsigned long b[];
};
Но при этом ругается компилятор на инициализацию такой структуры:
struct str =
{
10,
{ 1, 2, 3}
};

Error[Pe070]: incomplete type is not allowed - и ссылка на объявление структуры.
Так можно ли так делать, или нет?
vet
Код
struct str mystr =
{
10,
{ 1, 2, 3}
};
dxp
Цитата(Alechin @ Feb 7 2006, 13:29) *
Работаю в IAR 4.10A
По хелпу последним элементом структуры может быть незавершенный массив - вот как ее (структуру) объявляют в мануале на компилятор:
struct str
{
char a;
unsigned long b[];
};
Но при этом ругается компилятор на инициализацию такой структуры:
struct str =
{
10,
{ 1, 2, 3}
};

Error[Pe070]: incomplete type is not allowed - и ссылка на объявление структуры.
Так можно ли так делать, или нет?

А С++ случайно не включен? В С++ Incomplete types не разрешены. Только в С.
Alechin
Цитата
А С++ случайно не включен? В С++ Incomplete types не разрешены. Только в С.

Включен, мне нужны его фичи: инлайн функции, переопределения функций и т.п.
Жаль sad.gif

А тогда каким образом можно это обойти: пример структура с меню, содержит массив структур пунктов. Число пунктов может быть различно. Придется делать отдельно массив с пунктами мень, а в структуру меню вставлять адрес этого массива. А так как массив пунктов меню - это тоже набор указателей - в процедуре меню получается обращение по цепочке указателей, что мне не очень нравится.
dxp
Цитата(Alechin @ Feb 7 2006, 14:52) *
Цитата

А С++ случайно не включен? В С++ Incomplete types не разрешены. Только в С.

Включен, мне нужны его фичи: инлайн функции, переопределения функций и т.п.
Жаль sad.gif

А тогда каким образом можно это обойти: пример структура с меню, содержит массив структур пунктов. Число пунктов может быть различно. Придется делать отдельно массив с пунктами мень, а в структуру меню вставлять адрес этого массива. А так как массив пунктов меню - это тоже набор указателей - в процедуре меню получается обращение по цепочке указателей, что мне не очень нравится.

Почему не нравится? Именно так - через указатели на функции, - и делают подобные вещи. Конечно, при развесистых меню получится гора маловразумительного запутанного кода, и чтобы облегчить ситуацию тут, как раз, С++ные фичи и катят. Используйте для посторения меню возможности ООП. Т.е. создайте абстрактные базовые классы меню, элемента меню с чисто виртуальными (pure virtual) функциями. От них наследуйте конкретные классы, где переопределите эти функции. Все должно получиться элегантно и красиво. Множество ГУИев строится именно так.
Alechin
Цитата
Почему не нравится? Именно так - через указатели на функции, - и делают подобные вещи.Множество ГУИев строится именно так.

Такие вещи хороши в "динамических" системах - где что-то может добавляться/изменяться в процессе работы. У меня-же все жестко привязано: те-же менюшки раз и навсегда определены и зафиксированы в коде программы. Т.е. все "навороты" с цепочками указателей - просто не нужный оверхед. Я понимаю, что нынче это не принципиально - за каждый байт/такт не борятся, но все-же.
Кстати - огород с классами в программе на MSP430 настолько раздул код и стек, что я перестал влезать в контроллер. При переходе к простой структуре и дефайнам - все стало нормально (были конфигурационные таблицы - я решил сделать класс, где сами параметры защищенные члены, доступ через методы и т.п. На вид получилось элегантно, но результ см. выше. В итоге все было заменено на структуру с данными и макросы их чтения (для наглядности)).
Но ладно, это уже не по теме.
haker_fox
Насчет меню, может пригодится:
http://electronix.ru/forum/index.php?showt...%F0%E0%E8%E2%E0
dxp
Цитата(Alechin @ Feb 7 2006, 16:48) *
Цитата

Почему не нравится? Именно так - через указатели на функции, - и делают подобные вещи.Множество ГУИев строится именно так.

Такие вещи хороши в "динамических" системах - где что-то может добавляться/изменяться в процессе работы. У меня-же все жестко привязано: те-же менюшки раз и навсегда определены и зафиксированы в коде программы. Т.е. все "навороты" с цепочками указателей - просто не нужный оверхед. Я понимаю, что нынче это не принципиально - за каждый байт/такт не борятся, но все-же.
Кстати - огород с классами в программе на MSP430 настолько раздул код и стек, что я перестал влезать в контроллер.

Несколько странно. Интенсивно использую классы, виртуальные функции, не замечал, чтобы это давало заметный оверхед. На MSP430, например, вызов виртуальной функции по сравнению с вызовом обычной функции - это всего две быстрых (однотактовых) регистровых команды, т.е. практически незаметно. На AVR оверхед чуть больше, но тоже не давит. Т.ч. непонятно, откуда раздулся код и возникли дополнительные требования к размеру стека.

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

Что касается "динамических" систем, тоже не согласен. Если не надо ничего менять, то и не меняйте - заложите указатели в таблицы намертво. Таблицы эти (если большие) можно и во флешь затолкать.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.