Может быть я конечно не все понял, но в чем вобще проблема ?
Копирование из флеш в рам в вашей ситуации все равно придется делать "ручками"
Ну дык и кто мешает просто забить в памяти кусок максимального объема типа

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

Проблема в том, что программной памяти жалко (и так не хватает), это обстоятельство и не позволяет "просто забить в памяти кусок максимального объема типа".

Стоп. Термин "incomplete array" приведен в стандарте С. Термина open array там нет, поэтому я решил что rezident ошибся в термине и поправил его, чтобы интересующийся ответом мог дальше искать информацию по правильным ключевым словам. Ваша фраза наталкивает на мысль, что open array это совершенно иная (хоть и похожая) конструкция. Но ладно стандарт, даже гугля на первых двух страницах не дает ни одной тематической ссылки на запрос "c open array" (дальше не искал). Поэтому объясните, что же такое "open array". Судя по вашей реплике, они есть в С++, с ними дружит sizeof и из них можно делать массивы?

Как раз для размещения во флеш в этой задаче incomplete arrays подходят как нельзя лучше. А вот при работе в ОЗУ - да, динамическое выделение памяти выглядит красиво, но не в каждой задаче имеет смысл его использовать. Тогда можно по ситуации - или дин. память или присваивать указателю на такую структуру адрес заранее выделенного буфера и дальше работать с буфером как со структурой этого типа.

Вы поправляли меня.
Под open array, я привел конструкцию:
char A[1];
а не
char A[]
т.е. это обычный массив объявленный с количеством элементов = 1.
Но ничто не мешает нам обращаться к элементам A[1], A[2] и т.д., необходимо лишь быть уверенным, что обращаясь к этим элементам мы не затрем ничего лишнего. При дин. выделении памяти - мы определяем границу массива количеством выделенной под него памяти.


По ключевому слову incomplete он бы нашел не то, что я имел в виду.


Отличие выше, с sizeof он конечно же тоже не дружит, т.к. будет возвращена длина 1. Но sizeof не был перечислен в Вашем списке проблем, либо я невнимательно смотрел. В C++ нично не препятствует использованию таких конструкций.


Согласен.

А что, преобразование типа через void * не годится или имеется в виду то же? Если массивы есть, то кто им мешает располагаться во FLASH? Вроде этого и хотели. Добавить модификаторы const __flash ко всем элементам (кроме typedef), т.е. к массивам и структурам,
в вариант http://electronix.ru/forum/index.php?showt...32479&st=0# и свободно пользоваться - массивы нужной длины во FLASH, структуры для работы с ними - тоже, "лишнего" места - аж по одному указателю на 1 массив. Просто не очень понятно, зачем для const массивов создавать что-то динамическое? Если нужно копировать, то всё-равно будет нужно куда-то положить. Если не обязательно, то можно взять по указателю в любое время.

Не вижу принципиальных отличий.
К
char A[]
с тем же успехом можно обращаться через A[1], A[2] и так далее, "необходимо лишь быть уверенным" и далее по тексту.
Точно так же не дружит с sizeof(), только для char A[1] надо
ptr = malloc( sizeof(struct header) + data_len - 1);
а для char A[] надо
ptr = malloc( sizeof(struct header) + data_len);
что несколько более логично.

Т.е. разницы с точки зрения применения - нет.

Фактически,
char A[1]; - это старый добрый программистский трюк, основанный на том, что поля структуры расположены в памяти в том же порядке, в котором записаны в структуре (кстати, в C++ это не гарантируется, если я правильно помню).
char A[]; - это стандартизованный способ.

Кстати, GNU-тое расширение позволяло писать
char A[0];

Если нужно, то указателем вполне пожно пользоваться практически как read-only массивом
const char array[]="Preved!";
const char * ptr = &array[0];//это тот указатель, который предлагалось положить в структуру

...
char ptmp = ptr;
char x;
...
x = ptmp[5] ; //x = *(ptmp+5); или x = 'd';

Спрашивается, зачем массив, если размер нельзя узнать? Разве указателя недостаточно?

В контексте вопроса этой ветки разница есть, и очень существенная.
Так как
struct
{
char A[];
}

просто не воспримится многими компиляторами.

Честно говоря я уже в рассуждениях несколько потерял вопрос-первопричину. Пускай автор всётаки уточнит поподробнее что он хочет сделать и для чего. В этом случае будут грамотнее и конкретнее ответы.

Я поступал подобным образом именно для ОЗУ и динамического распределения. А для определения начала структуры создавал специальный указатель. На удивление получилось наглядно и красиво(для меня) и очень удобно при отладке(всё поддержено отладчиком).

Для размещения во флэш я просто использовал сами массивы и массив ссылок (к примеру). Также можно разместить ссылку и в структуре. Зачем создавать открытый массив во флэш мне несколько не понятно, в том случае если всё равно массив создаётся на этапе компиляции. Если же он создаётся на этапе исполнения, тогда всё правильно, но достаточно сложно работать будет.

Я это к чему? Возможно Вам предложат совершенно иной подход.

Кстати, Сергей, откуда ты взял, что ИАР поддерживает? Помнится у меня была подобная проблема, когда в зависимости от конкретной прикладной задачи прибора, нужно было хранить в сегменте INFO MSP430 наряду с определенным количеством констант еще произвольное описание масок для данных. Так вот предлагаемый тобой способ с incompete array не прокатил. Хотя я располагал массив как и положено в конце структуры констант. Пришлось определять его отдельно как константный байтовый массив с одновременной инициализацией его. А в самой программе писать свою функцию, разбирающую этот массив на данные нужной размерности.

Ах да! Пользовался я ИАР ЕВ430 3.30А.

в случае структур - гарантируется с атрибутом __packed

Поддерживает. Практически используется, ну и родной документ по IAR EW430:


Невероятно, разве только если не пытались совсем грубо:

Эта цитата означает что структура не может состоять только из одного incomplete array, я правильно понял? Нет, у меня была структура из разных переменных в конце которой я пытался вставить этот incomplete array. Не получилось. ИАР выдавал ошибку.
Кстати, могла ли быть эта ошибка вызвана тем, что объявлял я структуру с одновременной инициализацией ее в одном модуле, а использовал еще и в двух других. Естественно, что в других модулях был описан ее прототип с квалификатором extern.

Да.

Подтверждаю, что использую без всяких проблем.

Из хелпа. Да и тут вопрос задавал, когда в плюсах попробовал использовать и не прошло. Мне тут ответили, что все работает. Переключил в режим С, действительно скомпилилось. А в плюсах - никак. Долго думал. Потом понял, что сама идеология классов (и структур как частных случаев классов) из-за полиформизма такое не допускает. Меня интересовало именно в ОЗУ. Сделал через динамическое выделение байтового массива и накладывание структуры. Кстати (!) структуру описал как open array. Насчет использования incomplete array в разных файлах - тоже наталкивался, но не на ошибку а на варнинг, но сейчас не вспомню какой точно. Если есть интерес - могу попытаться воспроизвести. Если я правильно понял ваш исходник, вы пытались сделать массив из структур, содержащих incomplete array. А поскольку размер такой структуры неизвестен, то и массив из нее сделать никак.

P.S. вот читаешь всякие умные книжки, и так у них красиво все получается. Массив нужен из таких структур - пожалуйста: получите массив указателей на такие структуры. И писать можно data = Mystruct[1].data[3]. А вдумаешься - для этой "красоты" на каждую структуру лишний указатель. Выглядит красиво, но в нашей области в бОльшей части реальных задач неприменимо. Или динамическое выделение памяти - с ним задача из примера решается легко и естественно. А оно мне на меге8 с 1К ОЗУ как серпом по... И так практически с каждым примером. Снова порой ощущаю себя как когда с ассемблера на С переползал - "блин, какой тупой компилятор, здесь можно было команду сэкономить, здесь регистр, здесь такт". Может это пройдет, а может в этом есть и положительное - заставляет мозгами активнее шевелить.