Вопрос скорее по Си Опции

[_Артём_]

В программе объявлен такой тип данных

Код

#define MAX_DATA_SIZE 128
struct TStructure {
    unsigned char DataSize;// размер данных
    unsigned char Data[MAX_DATA_SIZE];
};

Соответственно есть переменные такого типа:

Код

struct TStructure st1={
    3,
    {1,2,3}
};
struct TStructure st1={
    1,
    {1}
};

Структуры должны хранится в программной памяти и загружаться в ОЗУ соответственно ситуации.
Проблема в том, что Data может быть разной длины (от 1 до 128), то есть программная память зря расходуется.
Как определить структуру, чтобы поле Data имела размер не больше чем требуется?

[rezident]

ИМХО, забейте на эту структуру! Объявите одномерный массив

Код

unsigned char Data[MAX_DATA_SIZE+1];

И интерпретируйте его первый элемент (Data[0]) как валидный размер текущего массива. Соответственно ваши данные располагайте, начиная со второго элемента массива (Data[1]).
P.S. я понимаю, когда в структуру объединяют разнотипные данные, но зачем для однотипных структуру-то создавать? Если только для того чтобы "красиво" в тексте исходника выглядело, дык дефайны для этого имеются, типа

Код

#define DataSize Data[0]

[zltigo]

ИМХО, забейте на эту структуру!

Совершенно неразумный совет.

И интерпретируйте его первый элемент (Data[0]) как валидный размер текущего массива.

Ну зачем, о Господи! Если совершенно естественно именуется поле структуры а уж его "интерпретацией" должен заниматься компилятор. Зачем забивать себе и другим лишними знаниями, соглашениями и потенциальными ошибками.

Пожалуй остановлюсь на массиве.

И, простите, как, это поможет проблеме???
Внимательно читайте пост defunct - Ваш вариант это динамическое выделение памяти.

[rezident]

Совершенно неразумный совет.

Вы как всегда категоричны Чем же он неразумен в применении к структуре однотипных переменных? Структура это всего лишь абстракция, предназначенная для удобства человека. Чтобы человек-программист мог на привычном для него объектном уровне изложить компилятору свою точку зрения на вид, размерность и порядок расположения переменных. Данные в памяти будут все равно в виде байтов, 16-ти или 32-разрядных слов располагаться, в соответствии со способом организации типа памяти конкретного МК.

Ну зачем, о Господи! Если совершенно естественно именуется поле структуры а уж его "интерпретацией" должен заниматься компилятор.

Собственно я об этом же, только без обращения к Творцу Только зачем она в приведенном автором топика примере?

Зачем забивать себе и другим лишними знаниями, соглашениями и потенциальными ошибками.

Тогда нужно на Паскале писать, а не на Си. Делов-то!

Внимательно читайте пост defunct - Ваш вариант это динамическое выделение памяти.

Читайте пост Сергея Борщ о том, какие проблемы бывают с незавершенными массивами.

[defunct]

Читайте пост Сергея Борщ о том, какие проблемы бывают с незавершенными массивами.

Вам бы тоже не помешало прочитать его пост и сравнить два термина "open array" и "incomplete array".
Проблемы перечисленные Сергеем не распространяются на open array, кроме одной -

1)такой массив может располагаться только в конце структуры

Ну а то что нельзя разместить во флеш - да.. Но в контексте AVR - флеша ведь в разы больше чем RAM'а, для чего могла потребоваться такая экономия?!

Вот только с выделением облом - автор хотел эти структуры во флеше хранить.

Во флеш можно хранить в удобном и нормальном для этого виде, также как у автора ветки - структуры фиксированной длинны. Экономия на мой взгляд может потребоваться во второй части задачи -
"загружаться в ОЗУ соответственно ситуации."
Вот тут как раз сэкономить поможет способ с дин. выделением памяти.

[Сергей Борщ]

сравнить два термина "open array" и "incomplete array".

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

Ну а то что нельзя разместить во флеш - да.. Но в контексте AVR - флеша ведь в разы больше чем RAM'а, для чего могла потребоваться такая экономия?!

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

[defunct]

Стоп. Термин "incomplete array" приведен в стандарте С. Термина open array там нет, поэтому я решил что rezident ошибся в термине и поправил его

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

, чтобы интересующийся ответом мог дальше искать информацию по правильным ключевым словам.

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

Поэтому объясните, что же такое "open array". Судя по вашей реплике, они есть в С++, с ними дружит sizeof и из них можно делать массивы?

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

Как раз для размещения во флеш в этой задаче incomplete arrays подходят как нельзя лучше.

Согласен.

[ReAl]

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

Не вижу принципиальных отличий.
К
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];