Сообщение Re[15]: Определение регулярных последовательностей статическ от 16.12.2024 14:56
Изменено 16.12.2024 16:13 rg45
Re[15]: Определение регулярных последовательностей статическ
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я ответил в том смысле, что с извращениями могу и сам, а менять одно извращение (традиционный сишный развесистый стиль, в котором все хотя бы хорошо видно и управляемо) на ненавистную магию (которая радует исключительно до того момента, когда из-за какой-нибудь мелкой ошибки все уродливые потроха этой магии не вылезут наружу) просто не вижу смысла.
Ну вот смотри, ты называешь предлагаемый мной подход извращением, не только не зная его реализации, но даже не представляя сценариев использования. Невольно возникает вопрос: а на чём ты основываешься в своих суждениях? Исключительно на каких-то личных неудачах, так ведь?
А между тем, мой подход, возможно, не прост в реализации, зато даёт как нельзя более простое и естественное использование. Например, рекурсивный обход дерева конфигурационных параметров из этого примера
Причем, SomeOperation, AnotherOperation, etc могут быть как run-time, так и compile-time операциями. Весь фокус, как можно догадаться, находится внутри aggregates::Apply, который лежит потихоньку в отдельном файле и есть не просит.
Вот теперь и суди, что является извращением, а что нет.
ЕМ>Я ответил в том смысле, что с извращениями могу и сам, а менять одно извращение (традиционный сишный развесистый стиль, в котором все хотя бы хорошо видно и управляемо) на ненавистную магию (которая радует исключительно до того момента, когда из-за какой-нибудь мелкой ошибки все уродливые потроха этой магии не вылезут наружу) просто не вижу смысла.
Ну вот смотри, ты называешь предлагаемый мной подход извращением, не только не зная его реализации, но даже не представляя сценариев использования. Невольно возникает вопрос: а на чём ты основываешься в своих суждениях? Исключительно на каких-то личных неудачах, так ведь?
А между тем, мой подход, возможно, не прост в реализации, зато даёт как нельзя более простое и естественное использование. Например, рекурсивный обход дерева конфигурационных параметров из этого примера
Автор: rg45
Дата: 14.12 23:23
мог бы выглядеть примерно так (сразу два варианта):Дата: 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);
}
Причем, SomeOperation, AnotherOperation, etc могут быть как run-time, так и compile-time операциями. Весь фокус, как можно догадаться, находится внутри aggregates::Apply, который лежит потихоньку в отдельном файле и есть не просит.
Вот теперь и суди, что является извращением, а что нет.
Re[15]: Определение регулярных последовательностей статическ
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я ответил в том смысле, что с извращениями могу и сам, а менять одно извращение (традиционный сишный развесистый стиль, в котором все хотя бы хорошо видно и управляемо) на ненавистную магию (которая радует исключительно до того момента, когда из-за какой-нибудь мелкой ошибки все уродливые потроха этой магии не вылезут наружу) просто не вижу смысла.
Ну вот смотри, ты называешь предлагаемый мной подход извращением, не только не зная его реализации, но даже не представляя сценариев использования. Невольно возникает вопрос: а на чём ты основываешься в своих суждениях? Исключительно на каких-то личных неудачах, так ведь?
А между тем, мой подход, возможно, не прост в реализации, зато даёт как нельзя более простое и естественное использование. Например, рекурсивный обход дерева конфигурационных параметров из этого примера
Понятно, что разных нюансов использование может быть гораздо больше, чем показано в примере. И операции могут быть как run-time, так и compile-time. Весь фокус, как можно догадаться, находится внутри aggregates::Apply, который лежит потихоньку в отдельном файле и есть не просит.
Вот теперь и суди, что является извращением, а что нет.
ЕМ>Я ответил в том смысле, что с извращениями могу и сам, а менять одно извращение (традиционный сишный развесистый стиль, в котором все хотя бы хорошо видно и управляемо) на ненавистную магию (которая радует исключительно до того момента, когда из-за какой-нибудь мелкой ошибки все уродливые потроха этой магии не вылезут наружу) просто не вижу смысла.
Ну вот смотри, ты называешь предлагаемый мной подход извращением, не только не зная его реализации, но даже не представляя сценариев использования. Невольно возникает вопрос: а на чём ты основываешься в своих суждениях? Исключительно на каких-то личных неудачах, так ведь?
А между тем, мой подход, возможно, не прост в реализации, зато даёт как нельзя более простое и естественное использование. Например, рекурсивный обход дерева конфигурационных параметров из этого примера
Автор: rg45
Дата: 14.12 23:23
мог бы выглядеть примерно так (сразу два варианта):Дата: 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, который лежит потихоньку в отдельном файле и есть не просит.
Вот теперь и суди, что является извращением, а что нет.