Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Только как организовать это все в какое-то подобие кортежа, не привлекая std::tuple и ненавистную магию?

Ну так я же задавал вопрос

Автор: rg45
Дата: 15.12 00:52

, интересно ли тебе такое решение. Ты ответил

Автор: Евгений Музыченко
Дата: 15.12 14:55

, что такое ты и сам можешь

Как я писал выше, существует решение, позволяющее работать с произвольными С++ структурами, как с кортежами, с применением всех стандарных утилит: std::get, std::apply, std::tuple_size, std::tuple_element, или с их самописными аналогами.

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

Блин, почему почти всё приходится писать по два раза?

Здравствуйте, kov_serg, Вы писали:

_>Если бы вы привели конкретный пример

Если предельно схематично, то как-то так:

enum ParameterType {
  PT_MaxNumberOfLines,
  PT_AllowedLineTypes,
  PT_UniqueKey,
  PT_LineConfig,
};

enum LineParameterType {
  LPT_Id,
  LPT_Name,
  LPT_Dir,
};

...

MyMagicListType const ParameterList {
  { PT_UniqueKey, "12345-67890 },
  { PT_AllowedLineTypes, LT_Mic | LT_DigitalOutput | LT_Speakers },
  { PT_LineConfig,
    { LPT_Name, "line1" },
    { LPT_Id, 12 },
    { LPT_Dir, LD_Input },
  },
  { PT_LineConfig,
    { LPT_Name, "line2" },
    { LPT_Id, 7 },
    { LPT_Dir, LD_Output },
  },
  { PT_MaxNumberOfLines, 5 },
};

В родном синтаксисе почти все это есть, не хватает сущей мелочи — возможности размещения литеральных значений в "самоопределенном" виде, где каждый элемент снабжается заголовком "это элемент типа T", "это увеличение вложенности", "это уменьшение вложенности". А известные мне средства организации подобных описаний через шаблонную магию слишком громоздки и корявы, чтоб я мог заставить себя их терпеть.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>В родном синтаксисе почти все это есть, не хватает сущей мелочи — возможности размещения литеральных значений в "самоопределенном" виде, где каждый элемент снабжается заголовком "это элемент типа T", "это увеличение вложенности", "это уменьшение вложенности". А известные мне средства организации подобных описаний через шаблонную магию слишком громоздки и корявы, чтоб я мог заставить себя их терпеть.

Типа такого:

struct Rec {
    enum Type { RT_End, RT_Int, RT_Cstr, RT_Rec, RT_Enter, RT_Leave };
    int type, id;
    union {
        int v_int;
        const char* v_cstr;
        struct Rec *v_rec;
    };
    Rec() : type(RT_End) {}
    Rec(int id,int v) : type(RT_Int), id(id), v_int(v) {}
    Rec(int id,const char* v) : type(RT_Cstr), id(id), v_cstr(v) {}
    Rec(int id,Rec *v) : type(RT_Rec), id(id), v_rec(v) {}
    struct Enter{}; Rec(Enter,int id) : type(RT_Enter), id(id) {}
    struct Leave{}; Rec(Leave) : type(RT_Leave) {}
};

#define STRUCT_BEGIN(id) { id,[](){static Rec _array[]={
#define STRUCT_END()     {}};return _array;}() },
#define R_ENTER(id)      { Rec::Enter(),id },
#define R_LEAVE()        { Rec::Leave() },

enum ParameterType { PT_MaxNumberOfLines, PT_AllowedLineTypes, PT_UniqueKey, PT_LineConfig };
enum LineParameterType { LPT_Id,LPT_Name,LPT_Dir };
enum LT { LT_Mic=1,LT_DigitalOutput=2,LT_Speakers=4 };
enum LD { LD_Input,LD_Output };

Rec ParameterList[]={
    { PT_UniqueKey,"12345-67890" },
    { PT_AllowedLineTypes,LT_Mic | LT_DigitalOutput | LT_Speakers },
    STRUCT_BEGIN(PT_LineConfig)
        { LPT_Name,"line1" },
        { LPT_Id,12 },
        { LPT_Dir,LD_Input },
    STRUCT_END()
    STRUCT_BEGIN(PT_LineConfig)
        { LPT_Name,"line2" },
        { LPT_Id,7 },
        { LPT_Dir,LD_Output },
    STRUCT_END()
    R_ENTER(PT_LineConfig)
        { LPT_Name,"line3" },
        { LPT_Id,12 },
        { LPT_Dir,LD_Input },
    R_LEAVE()    
    R_ENTER(PT_LineConfig)
        { LPT_Name,"line4" },
        { LPT_Id,7 },
        { LPT_Dir,LD_Output },
    R_LEAVE()
    { PT_MaxNumberOfLines,5 },
    {}
};

STRUCT_BEGIN/END — для вложенных списков
R_ENTER/LEAVE — если первый вариант не радует накладными расходами

Здравствуйте, rg45, Вы писали:

R>Ты ответил

Автор: Евгений Музыченко
Дата: 15.12 14:55

, что такое ты и сам можешь

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

R>Нет, не привлекая ненавистную шаблонной магию, сделать это нельзя.

Это я понял.

Здравствуйте, kov_serg, Вы писали:

_>Типа такого:

У Вас получается скомпилировать это с consteval? Мой прошлогодний VC++ отказывается.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>У Вас получается скомпилировать это с consteval? Мой прошлогодний VC++ отказывается.

consteval не умеет static. Поэтому там есть второй вариант без лямбд.

struct Rec {
    enum Type { RT_End, RT_Int, RT_Cstr, RT_Rec, RT_Enter, RT_Leave };
    int type, id;
    union {
        int v_int;
        const char* v_cstr;
        struct Rec *v_rec;
    };
    constexpr Rec() : type(RT_End),id(0),v_int(0) {}
    constexpr Rec(int id,int v) : type(RT_Int),id(id),v_int(v) {}
    constexpr Rec(int id,const char* v) : type(RT_Cstr),id(id),v_cstr(v) {}
    constexpr Rec(int id,Rec *v) : type(RT_Rec),id(id),v_rec(v) {}
    struct Enter{}; constexpr Rec(Enter,int id) : type(RT_Enter),id(id),v_int(0) {}
    struct Leave{}; constexpr Rec(Leave) : type(RT_Leave),id(0),v_int(0) {}
};

#define R_ENTER(id)      { Rec::Enter(),id },
#define R_LEAVE()        { Rec::Leave() },

enum ParameterType { PT_MaxNumberOfLines, PT_AllowedLineTypes, PT_UniqueKey, PT_LineConfig };
enum LineParameterType { LPT_Id,LPT_Name,LPT_Dir };
enum LT { LT_Mic=1,LT_DigitalOutput=2,LT_Speakers=4 };
enum LD { LD_Input,LD_Output };

const Rec ParameterList[]={
    { PT_UniqueKey,"12345-67890" },
    { PT_AllowedLineTypes,LT_Mic | LT_DigitalOutput | LT_Speakers },
    R_ENTER(PT_LineConfig)
        { LPT_Name,"line3" },
        { LPT_Id,12 },
        { LPT_Dir,LD_Input },
    R_LEAVE()    
    R_ENTER(PT_LineConfig)
        { LPT_Name,"line4" },
        { LPT_Id,7 },
        { LPT_Dir,LD_Output },
    R_LEAVE()
    { PT_MaxNumberOfLines,5 },
    {}
};

Если отдельно вложенные структуры определять то тоже constexpr работает: https://godbolt.org/z/rMTrsMbse

Здравствуйте, Евгений Музыченко, Вы писали:

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

Ну вот смотри, ты называешь предлагаемый мной подход извращением, не только не зная его реализации, но даже не представляя сценариев использования. Невольно возникает вопрос: а на чём ты основываешься в своих суждениях? Исключительно на каких-то личных неудачах, так ведь?

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

Автор: rg45
Дата: 14.12 23:23

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

//---------------------------------------------------------------------------------
auto SomeOperation(Numeric auto&&) {/*. . .*/}
auto SomeOperation(String auto&&) {/*. . .*/}
auto SomeOperation(Range auto&&) {/*. . .*/}

auto SomeOperation(Aggregate auto&& t)
{
    return aggregates::Apply(t, [](auto&&...x){ return (SomeOperation(x) | ...); });
}
//---------------------------------------------------------------------------------
struct {
    constexpr auto operator()(Numeric auto&&) const {/*. . .*/}
    constexpr auto operator()(String auto&&) const {/*. . .*/}
    constexpr auto operator()(Range auto&&) const {/*. . .*/}
    constexpr auto operator()(auto&&...) const {/*. . .*/}

    constexpr auto operator()(Aggregate auto&& t) const { return aggregates::Apply(t, *this}); }

} inline constexpr AnotherOperation;
//---------------------------------------------------------------------------------
struct {
// . . .
} inline constexpr Config;

int main()
{
    SomeOperation(Config);
    AnotherOperation(Config);
}

Понятно, что разных нюансов использования может быть гораздо больше, чем показано в примере. И операции могут быть как run-time, так и compile-time. Весь фокус, как можно догадаться, находится внутри aggregates::Apply, который лежит потихоньку в отдельном файле и есть не просит.

Вот теперь и суди, что является извращением, а что нет.

Здравствуйте, kov_serg, Вы писали:

_>consteval не умеет static.

Хм, странно. Почему? Какая ему разница, как использовать полученные константы — в выражениях или класть в память?

_>там есть второй вариант без лямбд.

Во, этот действительно создает в памяти то, что требуется. Спасибо! И работает, начиная с C++11, для меня это важно. Жаль, записей переменной длины не сделать, но это уже не критично, там особо нет смысла экономить память.

Здравствуйте, rg45, Вы писали:

R>ты называешь предлагаемый мной подход извращением, не только не зная его реализации, но даже не представляя сценариев использования.

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

R>на чём ты основываешься в своих суждениях? Исключительно на каких-то личных неудачах, так ведь?

В каком смысле "личных неудачах"? Какие "неудачи" тут могли бы иметь место?

R>Весь фокус, как можно догадаться, находится внутри aggregates::Apply, который лежит потихоньку в отдельном файле и есть не просит.

Ну вот не получается у меня отключиться от того, что лежит в таких файлах, даже если оно и "есть не просит". Само знание о том, что там лежит идеологически уродливый код, не позволяет мне его использовать спокойно и с удовольствием. Примерно так же было бы неприятно пользоваться вещами, которые заведомо краденые у приличных людей, сильно переживающих потерю. Я очень завидую тем, кто воспринимает шаблонную магию, как высшее достижение, и восхищается ею.

Здравствуйте, Евгений Музыченко, Вы писали:

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

ЕМ>Ну вот не получается у меня отключиться от того, что лежит в таких файлах, даже если оно и "есть не просит". Само знание о том, что там лежит идеологически уродливый код, не позволяет мне его использовать спокойно и с удовольствием. Примерно так же было бы неприятно пользоваться вещами, которые заведомо краденые у приличных людей, сильно переживающих потерю. Я очень завидую тем, кто воспринимает шаблонную магию, как высшее достижение, и восхищается ею.

Ну то есть, неприятие сугубо иррациональное. Я тебя понял.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Во, этот действительно создает в памяти то, что требуется. Спасибо! И работает, начиная с C++11, для меня это важно. Жаль, записей переменной длины не сделать, но это уже не критично, там особо нет смысла экономить память.

А что значит записей переменной длинны не сделать?

Здравствуйте, rg45, Вы писали:

R>неприятие сугубо иррациональное.

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

Здравствуйте, kov_serg, Вы писали:

_>что значит записей переменной длинны не сделать?

Использовать вместо union с набором полей независимые структуры разного наполнения и размера. Хотя, думаю, с наследованием это дело тоже должно работать, принципиально ничего не меняется.

Здравствуйте, Евгений Музыченко, Вы писали:

R>>неприятие сугубо иррациональное.

ЕМ>Оно как раз исключительно рациональное. Когда требуемые функции реализуются в изолированной библиотеке — мне по барабану, какие трюки там применяются, лишь бы работало надежно, и быстродействие и объем потребной памяти были адекватны функциональности. Пусть хоть трехслойную виртуализацию городят. А когда что-то реализовано на уровне исходного кода, который всегда будет соседствовать с моим, и мои случайные погрешности будут выворачивать наизнанку его потроха — нужны очень серьезные, прямо-таки радикальные выгоды, а таковых эта кухня предоставить не может.

Так а кто тебе запрещает иметь собственную изолированную библиотеку?

А быстродействие и объем памяти, ты приплёл уже лишь бы что-то приплести. Я тебе в этой теме уже несколько раз обосновал, что с этим подходом можно добиться нулевого импакта как по памяти, так и по быстродействию. При самых простых и естественных сценариях использования. Все выгоды налицо, по-моему. Куда уж радикальнее.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Использовать вместо union с набором полей независимые структуры разного наполнения и размера. Хотя, думаю, с наследованием это дело тоже должно работать, принципиально ничего не меняется.

Это решается элементарно. Предкомпиляцией.

1. Сначала компилируете небольшую программу которая сереализацует ваши параметы в бинарном виде -> который превращается в массив байтов (можно с красивыми коментариями что где захоронено)
2. Компилируете с подключением этих данных
3. profit

ps: можно сделать скрипт что бы убрать лишнюю компиляцию и упростить процес

Здравствуйте, rg45, Вы писали:

R>кто тебе запрещает иметь собственную изолированную библиотеку?

Возможности языка. Чтоб иметь в чистом виде то, что я хочу, нужен или традиционный сишный подход, или полностью внешние средства.

R>быстродействие и объем памяти, ты приплёл уже лишь бы что-то приплести.

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

R>с этим подходом можно добиться нулевого импакта как по памяти, так и по быстродействию.

На время компиляции тот подход никак не влияет? Время на поиск причин многоэтажных сообщений об ошибках тоже не учитывается?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Возможности языка. Чтоб иметь в чистом виде то, что я хочу, нужен или традиционный сишный подход, или полностью внешние средства.
ЕМ>Это я приплел по отношению к реально внешней библиотеке, которая полностью готова к выполнению, и никак не участвует в компиляции.

Короче, вредничаешь.

ЕМ>На время компиляции тот подход никак не влияет? Время на поиск причин многоэтажных сообщений об ошибках тоже не учитывается?

Ну небольшие издержки имеются, конечно Хотя, удар по времени компиляции, как правило, определяется не сложностью кода, а общей организацией кода. Если всё по уму делать, то издержки можно свести к минимуму.

Ну, не хочешь, как хочешь. Мне ещё и проще. А то пришлось бы еще время на прототип тратить.