Сообщение Re[3]: Определение регулярных последовательностей статически от 14.12.2024 20:23
Изменено 14.12.2024 20:25 rg45
Re[3]: Определение регулярных последовательностей статических д
Здравствуйте, Евгений Музыченко, Вы писали:
R>>Лень набрасывать код только ради примера. Одно из типичных применений — параметризуемые программы, настраиваемые на конкретного заказчика. Поначалу хватает набора простейших #define или констант, потом софт постепенно усложняется, добавляются новые параметры и их группы, которые уже замучишься перечислять в виде имен вида Node7_Channel3_TempMax, и вдобавок легко перепутать номера/индексы. А главное — в этой куче с ходу не видно структуры, ибо она делается в некотором роде подобно реляционным БД, где иерархия и группировка достигаются гибкими, но неочевидными способами.
ЕМ>Поэтому хочется это дело оформить в структурированно-иерархическом виде, как в cfg-файлах, виндовом реестре или том же JSON, чтоб максимум данных можно было задавать литералами. Чтоб в любой однородный перечень, указанный в отдельно взятом наборе параметров, можно было тупо вставить дополнительный элемент, и это не ломало соответствия с предопределенным типом и/или форматами остальных наборов параметров.
ЕМ>Я знаю, что можно наплодить классов, наделать из них полиморфных объектов, но инициализировать и собирать в контейнеры это все можно только во время выполнения. Поскольку я примерно представляю, в какой жирный и уродливый код это будет раскрываться, мне заранее противно даже думать в эту сторону.
Просто, чтоб мне стало понятно. Можешь объяснить, что не подходит в решении "в лоб"?
http://coliru.stacked-crooked.com/a/9567017a72329a8a
R>>Лень набрасывать код только ради примера. Одно из типичных применений — параметризуемые программы, настраиваемые на конкретного заказчика. Поначалу хватает набора простейших #define или констант, потом софт постепенно усложняется, добавляются новые параметры и их группы, которые уже замучишься перечислять в виде имен вида Node7_Channel3_TempMax, и вдобавок легко перепутать номера/индексы. А главное — в этой куче с ходу не видно структуры, ибо она делается в некотором роде подобно реляционным БД, где иерархия и группировка достигаются гибкими, но неочевидными способами.
ЕМ>Поэтому хочется это дело оформить в структурированно-иерархическом виде, как в cfg-файлах, виндовом реестре или том же JSON, чтоб максимум данных можно было задавать литералами. Чтоб в любой однородный перечень, указанный в отдельно взятом наборе параметров, можно было тупо вставить дополнительный элемент, и это не ломало соответствия с предопределенным типом и/или форматами остальных наборов параметров.
ЕМ>Я знаю, что можно наплодить классов, наделать из них полиморфных объектов, но инициализировать и собирать в контейнеры это все можно только во время выполнения. Поскольку я примерно представляю, в какой жирный и уродливый код это будет раскрываться, мне заранее противно даже думать в эту сторону.
Просто, чтоб мне стало понятно. Можешь объяснить, что не подходит в решении "в лоб"?
http://coliru.stacked-crooked.com/a/9567017a72329a8a
#include <iostream>
#include <string>
struct
{
struct {
bool Value_A = true;
int Value_B = 42;
double Value_C = 3.14;
std::string Value_D = "Hello";
} Key_A;
struct {
struct {
bool Value_A = true;
int Value_B = 42;
double Value_C = 3.14;
std::string Value_D = "Hello";
} Key_X;
bool Value_A = true;
int Value_B = 42;
double Value_C = 3.14;
std::string Value_D = "Hello";
} Key_B;
struct {
bool Value_A = true;
int Value_B = 42;
double Value_C = 3.14;
std::string Value_D = "Hello";
} Key_C;
} inline constexpr Config;
int main()
{
std::cout << Config.Key_B.Key_X.Value_C << std::endl;
}
Re[3]: Определение регулярных последовательностей статически
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Лень набрасывать код только ради примера. Одно из типичных применений — параметризуемые программы, настраиваемые на конкретного заказчика. Поначалу хватает набора простейших #define или констант, потом софт постепенно усложняется, добавляются новые параметры и их группы, которые уже замучишься перечислять в виде имен вида Node7_Channel3_TempMax, и вдобавок легко перепутать номера/индексы. А главное — в этой куче с ходу не видно структуры, ибо она делается в некотором роде подобно реляционным БД, где иерархия и группировка достигаются гибкими, но неочевидными способами.
ЕМ>Поэтому хочется это дело оформить в структурированно-иерархическом виде, как в cfg-файлах, виндовом реестре или том же JSON, чтоб максимум данных можно было задавать литералами. Чтоб в любой однородный перечень, указанный в отдельно взятом наборе параметров, можно было тупо вставить дополнительный элемент, и это не ломало соответствия с предопределенным типом и/или форматами остальных наборов параметров.
ЕМ>Я знаю, что можно наплодить классов, наделать из них полиморфных объектов, но инициализировать и собирать в контейнеры это все можно только во время выполнения. Поскольку я примерно представляю, в какой жирный и уродливый код это будет раскрываться, мне заранее противно даже думать в эту сторону.
Просто, чтоб мне стало понятно. Можешь объяснить, что не подходит в решении "в лоб"?
http://coliru.stacked-crooked.com/a/9567017a72329a8a
Это же и есть тот самый "структурированно-иерархический вид, как в cfg-файлах, виндовом реестре или том же JSON", о котором ты мечтаешь.
ЕМ>Лень набрасывать код только ради примера. Одно из типичных применений — параметризуемые программы, настраиваемые на конкретного заказчика. Поначалу хватает набора простейших #define или констант, потом софт постепенно усложняется, добавляются новые параметры и их группы, которые уже замучишься перечислять в виде имен вида Node7_Channel3_TempMax, и вдобавок легко перепутать номера/индексы. А главное — в этой куче с ходу не видно структуры, ибо она делается в некотором роде подобно реляционным БД, где иерархия и группировка достигаются гибкими, но неочевидными способами.
ЕМ>Поэтому хочется это дело оформить в структурированно-иерархическом виде, как в cfg-файлах, виндовом реестре или том же JSON, чтоб максимум данных можно было задавать литералами. Чтоб в любой однородный перечень, указанный в отдельно взятом наборе параметров, можно было тупо вставить дополнительный элемент, и это не ломало соответствия с предопределенным типом и/или форматами остальных наборов параметров.
ЕМ>Я знаю, что можно наплодить классов, наделать из них полиморфных объектов, но инициализировать и собирать в контейнеры это все можно только во время выполнения. Поскольку я примерно представляю, в какой жирный и уродливый код это будет раскрываться, мне заранее противно даже думать в эту сторону.
Просто, чтоб мне стало понятно. Можешь объяснить, что не подходит в решении "в лоб"?
http://coliru.stacked-crooked.com/a/9567017a72329a8a
#include <iostream>
#include <string>
struct
{
struct {
bool Value_A = true;
int Value_B = 42;
double Value_C = 3.14;
std::string Value_D = "Hello";
} Key_A;
struct {
struct {
bool Value_A = true;
int Value_B = 42;
double Value_C = 3.14;
std::string Value_D = "Hello";
} Key_X;
bool Value_A = true;
int Value_B = 42;
double Value_C = 3.14;
std::string Value_D = "Hello";
} Key_B;
struct {
bool Value_A = true;
int Value_B = 42;
double Value_C = 3.14;
std::string Value_D = "Hello";
} Key_C;
} inline constexpr Config;
int main()
{
std::cout << Config.Key_B.Key_X.Value_C << std::endl;
}
Это же и есть тот самый "структурированно-иерархический вид, как в cfg-файлах, виндовом реестре или том же JSON", о котором ты мечтаешь.