|
|
  |
Не получается разместить в структуре неполный (Incomplete) массив |
|
|
|
Feb 7 2006, 07:46
|
Знающий
   
Группа: Свой
Сообщений: 550
Регистрация: 16-06-04
Из: Казань
Пользователь №: 32

|
Код struct str mystr = { 10, { 1, 2, 3} };
--------------------
Главная линия этого опуса ясна мне насквозь!
|
|
|
|
|
Feb 7 2006, 08:52
|
Частый гость
 
Группа: Свой
Сообщений: 158
Регистрация: 27-06-05
Из: Химки, Моск.обл.
Пользователь №: 6 334

|
Цитата А С++ случайно не включен? В С++ Incomplete types не разрешены. Только в С. Включен, мне нужны его фичи: инлайн функции, переопределения функций и т.п. Жаль  А тогда каким образом можно это обойти: пример структура с меню, содержит массив структур пунктов. Число пунктов может быть различно. Придется делать отдельно массив с пунктами мень, а в структуру меню вставлять адрес этого массива. А так как массив пунктов меню - это тоже набор указателей - в процедуре меню получается обращение по цепочке указателей, что мне не очень нравится.
|
|
|
|
|
Feb 7 2006, 10:23
|

Adept
     
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343

|
Цитата(Alechin @ Feb 7 2006, 14:52)  Цитата А С++ случайно не включен? В С++ Incomplete types не разрешены. Только в С.
Включен, мне нужны его фичи: инлайн функции, переопределения функций и т.п. Жаль  А тогда каким образом можно это обойти: пример структура с меню, содержит массив структур пунктов. Число пунктов может быть различно. Придется делать отдельно массив с пунктами мень, а в структуру меню вставлять адрес этого массива. А так как массив пунктов меню - это тоже набор указателей - в процедуре меню получается обращение по цепочке указателей, что мне не очень нравится. Почему не нравится? Именно так - через указатели на функции, - и делают подобные вещи. Конечно, при развесистых меню получится гора маловразумительного запутанного кода, и чтобы облегчить ситуацию тут, как раз, С++ные фичи и катят. Используйте для посторения меню возможности ООП. Т.е. создайте абстрактные базовые классы меню, элемента меню с чисто виртуальными (pure virtual) функциями. От них наследуйте конкретные классы, где переопределите эти функции. Все должно получиться элегантно и красиво. Множество ГУИев строится именно так.
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
Feb 7 2006, 10:48
|
Частый гость
 
Группа: Свой
Сообщений: 158
Регистрация: 27-06-05
Из: Химки, Моск.обл.
Пользователь №: 6 334

|
Цитата Почему не нравится? Именно так - через указатели на функции, - и делают подобные вещи.Множество ГУИев строится именно так. Такие вещи хороши в "динамических" системах - где что-то может добавляться/изменяться в процессе работы. У меня-же все жестко привязано: те-же менюшки раз и навсегда определены и зафиксированы в коде программы. Т.е. все "навороты" с цепочками указателей - просто не нужный оверхед. Я понимаю, что нынче это не принципиально - за каждый байт/такт не борятся, но все-же. Кстати - огород с классами в программе на MSP430 настолько раздул код и стек, что я перестал влезать в контроллер. При переходе к простой структуре и дефайнам - все стало нормально (были конфигурационные таблицы - я решил сделать класс, где сами параметры защищенные члены, доступ через методы и т.п. На вид получилось элегантно, но результ см. выше. В итоге все было заменено на структуру с данными и макросы их чтения (для наглядности)). Но ладно, это уже не по теме.
|
|
|
|
|
Feb 8 2006, 06:52
|

Adept
     
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343

|
Цитата(Alechin @ Feb 7 2006, 16:48)  Цитата Почему не нравится? Именно так - через указатели на функции, - и делают подобные вещи.Множество ГУИев строится именно так.
Такие вещи хороши в "динамических" системах - где что-то может добавляться/изменяться в процессе работы. У меня-же все жестко привязано: те-же менюшки раз и навсегда определены и зафиксированы в коде программы. Т.е. все "навороты" с цепочками указателей - просто не нужный оверхед. Я понимаю, что нынче это не принципиально - за каждый байт/такт не борятся, но все-же. Кстати - огород с классами в программе на MSP430 настолько раздул код и стек, что я перестал влезать в контроллер. Несколько странно. Интенсивно использую классы, виртуальные функции, не замечал, чтобы это давало заметный оверхед. На MSP430, например, вызов виртуальной функции по сравнению с вызовом обычной функции - это всего две быстрых (однотактовых) регистровых команды, т.е. практически незаметно. На AVR оверхед чуть больше, но тоже не давит. Т.ч. непонятно, откуда раздулся код и возникли дополнительные требования к размеру стека. Вот чем можно легко и незаметно разудуть код и потребляемую память - так это шаблоны.  Тут надо аккуратно следить и думать при инстанцировании. Но оверхед от приемения классов (даже с виртуальными функциями) очень мал, практически программа по быстродействию и размеру не будет отличаться от программы с той же функциональностью, написанной на С. Что касается "динамических" систем, тоже не согласен. Если не надо ничего менять, то и не меняйте - заложите указатели в таблицы намертво. Таблицы эти (если большие) можно и во флешь затолкать.
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|