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

[_Артём_]

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

Код

#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 имела размер не больше чем требуется?

[singlskv]

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

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

Код

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

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

[_Артём_]

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

Код

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

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

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

[tag]

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

...непонятно, предполагается что структура размещается в ОЗУ, а не в программной памяти и данные в нее заносятся из flash... у вас нехватка какой памяти программ или ОЗУ данных?

[_Артём_]

...непонятно, предполагается что структура размещается в ОЗУ, а не в программной памяти и данные в нее заносятся из flash... у вас нехватка какой памяти программ или ОЗУ данных?

Нехватка у меня памяти программ(это к слову).
Вариант Сергея Борща почему-то в С++ глючит (то работает, то нет).
Наверное буду использовать другие варианты (скорее всего двоичный массив нужной длины).

Пожалуй, тему пора закрывать - сказано более, чем достаточно...
Всем спасибо.

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

А про С++ в вопросе не было!

Вариант Сергея Борща почему-то в С++ глючит (то работает, то нет).

Как заставить Американца прыгнуть с моста? Встретить его на мосту и убедить, что он разорен. Как заставить француза прыгнуть с моста? Встретить его на мосту и убедить, что жена ему изменяет. Как заставить русского прыгнуть с моста? Встретить его на мосту и сказать "А вы знаете, здесь прыгать с моста запрещено!"

4) В С++ такое уже не прокатит.

В С++ такое не работает по простой причине: при наследовании данные производной структуры (которая в С++ есть частный случай класса) располагаются вслед за данными родителя. А если размер родителя неизвестен, компилятор не сможет иметь доступ к данным производного класса. А сказать "от этого класса наследников не будет никогда" возможности нет. Как сделать на С++ то, что вы хотите, да еще с инициализацией через {} - не знаю Могу предложить два варианта - 1) массив структур сам по себе, структура из размера и указателя на массив. Да, лишний указатель, зато можно писать a = pArray[n].member; 2) не указывать размер, а в конце масива добавлять элемент с каким-либо признаком конца структуры (например если одно из полей - указатель, то он равен нулю.

Код

class terminal_t
{
public:
    terminal_t() {};
    static void process();
private:
    static bool read_input(char c);
public:

private:
    ................
    struct dictionary_t
    {
        char Name[10];
        void (*Action)(void);
        uint8_t StackRequired;
    } static const __flash Dictionary[];
} static Terminal;

#define    TERMINAL_DICTIONARY                      \
terminal_t::dictionary_t const __flash terminal_t::Dictionary[] =   \
{                                                                    \
    { "HEX",        ns_terminal::SetHex,     0},             \
    { "DECIMAL",    ns_terminal::DECIMAL,    0},             \
    { ".",          ns_terminal::UDOT,       1},             \
    { "@",          ns_terminal::Reference,  1},             \
    { "!",          ns_terminal::Dereference, 2},            \
    {"DUMP",        ns_terminal::DUMP,       2},             \

#define    TERMINAL_DICTIONARY_END                  \
    {0,        0 }                                    \
};


TERMINAL_DICTIONARY
    {"v",    readADC, 0},
    {"IDUMP",   RAM_DUMP, 2},
    {"RDUMP",   XROM_DUMP, 3},
    {"XDUMP",   XRAM_DUMP, 2},
    {"X!",      writeRAM, 2},
    {"X@",      readRAM, 1},
    {"RB!",     writeROM_byte, 3},
    {"R!",      writeROM, 3},
    {"R@",      readROM, 2},
    {"SN",      SN, 0},
TERMINAL_DICTIONARY_END

Да, на каждую структуру лишний элемент, но не нужно вручную перед компиляцией считать количество элементов, а значит и ошибиться невозможно. И те же самые Dictionary[n].Action();

[ReAl]

В С++ такое не работает по простой причине: при наследовании данные производной структуры (которая в С++ есть частный случай класса) располагаются вслед за данными родителя. А если размер родителя неизвестен, компилятор не сможет иметь доступ к данным производного класса.

Более того, даже без учёта incomplete array порядок размещения полей гарантируется только если у класса нет чередования модификаторов доступа (public/protected/private), нет виртуальных функций и базовых классов.

Т.е. тут порядок в памяти будет как написано
class foo {
int i;
int j;
int k;
};

а тут уже "не гарантируется", хотя и, вероятнее всего, будет всё нормально.
struct moo {
int i;
protected:
int j;
public:
int k;
};

gcc без ключа полного соответствия стандарту (--pedantic) пропускает incomplete arrays и вроде бы всё нормально компилирует... Но при этом не ругается даже если вывести потомка.

На мой взгляд, если уж припёрло, лучше бы такое выделить в отдельный чисто-С-шный модуль и обернуть в вызовы (чтобы сами структуры наружу даже не блестели). Или таки разориться на указатели в структурах а массивы держать отдельно.

[Oldring]

На мой взгляд, если уж припёрло, лучше бы такое выделить в отдельный чисто-С-шный модуль и обернуть в вызовы (чтобы сами структуры наружу даже не блестели). Или таки разориться на указатели в структурах а массивы держать отдельно.

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

[rezident]

Если уж совершенно приперло с памятью - хранить все в одномерном байтовом массиве, и разориться на написание программы - упаковщика, порождающего сишный исходник с этим байтовым массивом.

Я это предлагал в самом начале, но меня обругали за такое предложение

[Oldring]

Я это предлагал в самом начале, но меня обругали за такое предложение

Не переживайте - собеседники просто знают толк в извращениях