Re: Определение регулярных последовательностей статических данных
От: Nuzhny Россия https://github.com/Nuzhny007
Дата: 15.12.24 06:16
Оценка: -1 :)
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Внешние средства оформления/компиляции не годятся — в большинстве случаев требуется использовать стандартные типы/значения из разных SDK для C/C++.


А protobuf/flatbuffers не подойдут? Они внешние, но работают на этапе компиляции. Можно в message запихать любых типов, те, которые не будут использоваться, не будут и сериализовывааться. Плюс, они кроссплатформенны, кросс языковые и т.д. Можно в бинарном виде хранить, можно, например для отладки, в json сохранять.
Re[9]: Определение регулярных последовательностей статически
От: kov_serg Россия  
Дата: 16.12.24 12:20
Оценка: 7 (1)
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>У Вас получается скомпилировать это с 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
Отредактировано 16.12.2024 13:18 kov_serg . Предыдущая версия . Еще …
Отредактировано 16.12.2024 13:16 kov_serg . Предыдущая версия .
Отредактировано 16.12.2024 12:55 kov_serg . Предыдущая версия .
Отредактировано 16.12.2024 12:52 kov_serg . Предыдущая версия .
Отредактировано 16.12.2024 12:48 kov_serg . Предыдущая версия .
Re: Определение регулярных последовательностей статических данных
От: kov_serg Россия  
Дата: 14.12.24 18:41
Оценка: :)
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>В C/C++ это традиционно делается через определение типов всех возможных данных, размещение каждого элемента данных в отдельной переменной/объекте, с последующим собиранием указателей на все это в линейный массив.


getValue(id) ?

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

https://en.wikipedia.org/wiki/Key%E2%80%93value_database
https://arrow.apache.org/

ЕМ>Внешние средства оформления/компиляции не годятся — в большинстве случаев требуется использовать стандартные типы/значения из разных SDK для C/C++.

Тогда генерировать скриптом (на php,perl,lua,python,...) data.cpp и data.h

ЕМ>В стандарты C++ последних лет ничего такого не завезли?

В последнии стандарты завезли уйму дури, вам какую?
Re[11]: Определение регулярных последовательностей статическ
От: rg45 СССР  
Дата: 15.12.24 15:37
Оценка: +1
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Доступа в compile-time мне вообще не нужно — только в run-time.


По-моему, ты сам себе противоречишь. Вот здесь
Автор: Евгений Музыченко
Дата: 15.12 14:55
ты говорил, что хочешь по максимуму статических определений на этапе компиляции. Так я тебе именно это и предлагаю.

ЕМ>Но Ваш вариант, как я понял, плотно завязан на RTTI,


Полностью мимо. Я всю дорогу пишу про компайл-тайм, тут на тебе — RTTI. Как, вообще, можно было сделать такой вывод из того, что я писал?

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


Это я вообще не распарсил. Какое отношение это имеет к тому, что я пишу?

Ты, вообще, читаешь, что я тебе пишу?
--
Справедливость выше закона. А человечность выше справедливости.
Отредактировано 15.12.2024 15:47 rg45 . Предыдущая версия . Еще …
Отредактировано 15.12.2024 15:41 rg45 . Предыдущая версия .
Отредактировано 15.12.2024 15:41 rg45 . Предыдущая версия .
Отредактировано 15.12.2024 15:39 rg45 . Предыдущая версия .
Re[14]: Определение регулярных последовательностей статическ
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 16.12.24 11:38
Оценка: :)
Здравствуйте, rg45, Вы писали:

R>Ты ответил
Автор: Евгений Музыченко
Дата: 15.12 14:55
, что такое ты и сам можешь


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

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


Это я понял.
Re[12]: Определение регулярных последовательностей статически
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 17.12.24 09:30
Оценка: :)
Здравствуйте, kov_serg, Вы писали:

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


Использовать вместо union с набором полей независимые структуры разного наполнения и размера. Хотя, думаю, с наследованием это дело тоже должно работать, принципиально ничего не меняется.
Re[21]: Определение регулярных последовательностей статическ
От: rg45 СССР  
Дата: 17.12.24 11:44
Оценка: +1
Здравствуйте, Евгений Музыченко, Вы писали:

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

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

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

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


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

Ну, не хочешь, как хочешь. Мне ещё и проще. А то пришлось бы еще время на прототип тратить.
--
Справедливость выше закона. А человечность выше справедливости.
Отредактировано 17.12.2024 11:48 rg45 . Предыдущая версия .
Определение регулярных последовательностей статических данных
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 14.12.24 15:42
Оценка:
Периодически возникает потребность определить десятки-сотни элементов статических/константных данных (числовых/логических значений, строк, указателей), произвольным образом объединенных в структуры/массивы — для описания различных концепций.

В языках "сверхвысокого" уровня это традиционно делается через XML/JSON — последовательность данных задается в литеральном виде, компилятор/интерпретатор ее как-то кодирует, и затем ее можно обходить, извлекая сведения о типе каждого элемента и его содержимом.

В C/C++ это традиционно делается через определение типов всех возможных данных, размещение каждого элемента данных в отдельной переменной/объекте, с последующим собиранием указателей на все это в линейный массив.

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

Внешние средства оформления/компиляции не годятся — в большинстве случаев требуется использовать стандартные типы/значения из разных SDK для C/C++.

В стандарты C++ последних лет ничего такого не завезли?
Re: Определение регулярных последовательностей статических д
От: rg45 СССР  
Дата: 14.12.24 18:28
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Периодически возникает потребность определить десятки-сотни элементов статических/константных данных (числовых/логических значений, строк, указателей), произвольным образом объединенных в структуры/массивы — для описания различных концепций.


ЕМ>В языках "сверхвысокого" уровня это традиционно делается через XML/JSON — последовательность данных задается в литеральном виде, компилятор/интерпретатор ее как-то кодирует, и затем ее можно обходить, извлекая сведения о типе каждого элемента и его содержимом.


ЕМ>В C/C++ это традиционно делается через определение типов всех возможных данных, размещение каждого элемента данных в отдельной переменной/объекте, с последующим собиранием указателей на все это в линейный массив.


Нифига не понял. Десятки-сотни констант разных типов, объединяются в структуры/массивы, оптять же, разных типов и указатели на всё это богатство каким-то магическим образом собираются в один линейный массив. Там массив void* что ли? Ты бы хоть эскиз кода набросал какой-то.
--
Справедливость выше закона. А человечность выше справедливости.
Отредактировано 14.12.2024 18:34 rg45 . Предыдущая версия . Еще …
Отредактировано 14.12.2024 18:33 rg45 . Предыдущая версия .
Отредактировано 14.12.2024 18:29 rg45 . Предыдущая версия .
Re[2]: Определение регулярных последовательностей статических д
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 14.12.24 19:31
Оценка:
Здравствуйте, rg45, Вы писали:

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


R>Там массив void* что ли?


Если всё совершенно разнородное, то или void*, или указатели на самый общий union, из которого парсер потом добывает нужный тип по общему полю селектора.

Ты бы хоть эскиз кода набросал какой-то.

R>Лень набрасывать код только ради примера. Одно из типичных применений — параметризуемые программы, настраиваемые на конкретного заказчика. Поначалу хватает набора простейших #define или констант, потом софт постепенно усложняется, добавляются новые параметры и их группы, которые уже замучишься перечислять в виде имен вида Node7_Channel3_TempMax, и вдобавок легко перепутать номера/индексы. А главное — в этой куче с ходу не видно структуры, ибо она делается в некотором роде подобно реляционным БД, где иерархия и группировка достигаются гибкими, но неочевидными способами.


Поэтому хочется это дело оформить в структурированно-иерархическом виде, как в cfg-файлах, виндовом реестре или том же JSON, чтоб максимум данных можно было задавать литералами. Чтоб в любой однородный перечень, указанный в отдельно взятом наборе параметров, можно было тупо вставить дополнительный элемент, и это не ломало соответствия с предопределенным типом и/или форматами остальных наборов параметров.

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

На любом приличном ассемблере я б наделал макросов, и изящно описал бы структуру данных любой сложности.
Re[2]: Определение регулярных последовательностей статических данных
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 14.12.24 19:47
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>https://en.wikipedia.org/wiki/Key%E2%80%93value_database


Нечто вроде, но нужны values любых поддерживаемых типов.

_>https://arrow.apache.org/


Судя по описанию, это что-то необъятное, претендующее на всеобщность. Мне точно имеет смысл это изучать?

_>Тогда генерировать скриптом (на php,perl,lua,python,...) data.cpp и data.h



Это будет еще более громоздко и запутанно, чем традиционный сишный способ.

_>В последнии стандарты завезли уйму дури


Ужас. Это вместо того, чтоб уже закопать стюардессу препроцессор...
Re[3]: Определение регулярных последовательностей статически
От: rg45 СССР  
Дата: 14.12.24 20:23
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Лень набрасывать код только ради примера. Одно из типичных применений — параметризуемые программы, настраиваемые на конкретного заказчика. Поначалу хватает набора простейших #define или констант, потом софт постепенно усложняется, добавляются новые параметры и их группы, которые уже замучишься перечислять в виде имен вида Node7_Channel3_TempMax, и вдобавок легко перепутать номера/индексы. А главное — в этой куче с ходу не видно структуры, ибо она делается в некотором роде подобно реляционным БД, где иерархия и группировка достигаются гибкими, но неочевидными способами.


ЕМ>Поэтому хочется это дело оформить в структурированно-иерархическом виде, как в cfg-файлах, виндовом реестре или том же JSON, чтоб максимум данных можно было задавать литералами. Чтоб в любой однородный перечень, указанный в отдельно взятом наборе параметров, можно было тупо вставить дополнительный элемент, и это не ломало соответствия с предопределенным типом и/или форматами остальных наборов параметров.


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


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

Просто чтоб мне стало понятно. Можешь объяснить, чем тебе не угодило решение "в лоб"? Вот тебе тот самый "структурированно-иерархический вид, как в cfg-файлах, виндовом реестре или том же JSON", о котором ты мечтаешь:

http://coliru.stacked-crooked.com/a/3b1f70e075579f52

#include <array>
#include <cstdint>
#include <iostream>
#include <string>

struct
{
    struct {
        bool Value_A = true;
        int Value_B = 42;
        double Value_C = 3.14;
        std::string Value_D = "Hello";
        std::array<uint8_t, 16> Value_E {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F};
    } Key_A;

    struct {
        struct {
            bool Value_A = true;
            int Value_B = 42;
            double Value_C = 3.14;
            std::string Value_D = "Hello";
            std::array<uint8_t, 16> Value_E {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F};
        } Key_X;

        bool Value_A = true;
        int Value_B = 42;
        double Value_C = 3.14;
        std::string Value_D = "Hello";
        std::array<uint8_t, 16> Value_E {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F};
    } Key_B;

    struct {
        bool Value_A = true;
        int Value_B = 42;
        double Value_C = 3.14;
        std::string Value_D = "Hello";
        std::array<uint8_t, 16> Value_E {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F};
    } Key_C;

    
} inline constexpr Config;

int main()
{
    std::cout << Config.Key_B.Key_X.Value_C << std::endl;
}


А редактор студии позволит ещё и коллапсить отдельные секции. Будет ни чуть не хуже, чем regedit.
--
Справедливость выше закона. А человечность выше справедливости.
Отредактировано 14.12.2024 21:39 rg45 . Предыдущая версия . Еще …
Отредактировано 14.12.2024 21:30 rg45 . Предыдущая версия .
Отредактировано 14.12.2024 21:03 rg45 . Предыдущая версия .
Отредактировано 14.12.2024 20:37 rg45 . Предыдущая версия .
Отредактировано 14.12.2024 20:34 rg45 . Предыдущая версия .
Отредактировано 14.12.2024 20:33 rg45 . Предыдущая версия .
Отредактировано 14.12.2024 20:26 rg45 . Предыдущая версия .
Отредактировано 14.12.2024 20:26 rg45 . Предыдущая версия .
Отредактировано 14.12.2024 20:25 rg45 . Предыдущая версия .
Re[4]: Определение регулярных последовательностей статически
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 14.12.24 21:42
Оценка:
Здравствуйте, rg45, Вы писали:

R>Ну то есть, это просто конфигурация программы, задаваемая в коде?


Да, причем исключительно (ну, или почти) на этапе компиляции.

R>А откуда берется желание запихнуть её в массив?


Чтобы можно было задавать только необходимые параметры, а добавление поддержки новых параметров не ломало существующих конфигураций.

R>Вот тебе тот самый "структурированно-иерархический вид


Как его обойти универсальным парсером, который в общем случае не знает, какие параметры (и каких типов) включены в конкретную конфигурацию?

R>как в cfg-файлах, виндовом реестре или том же JSON", о котором ты мечтаешь:


Это совершенно не то, о чем я мечтаю. Здесь доступ к параметрам возможен только по заранее известным именам. Такое у меня уже есть, не нравится.
Re[5]: Определение регулярных последовательностей статически
От: rg45 СССР  
Дата: 14.12.24 21:52
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

R>>Вот тебе тот самый "структурированно-иерархический вид


ЕМ>Как его обойти универсальным парсером, который в общем случае не знает, какие параметры (и каких типов) включены в конкретную конфигурацию?


Ну вот я же это и пытаюсь у тебя выведать. Зачем нужно обходить эту структуру каким-то парсером?

P.S. Есть подход, который позволяет работать с произвольными С++ структурами как с кортежами с использованием стандарных утилит std::get, std::apply, std::tuple_size, std::tuple_element (ну или с самописными аналогами). Ну и само собой, организовать рекурсивный обход структуры не составит труда при этом. Этот подход обеспечивает возможность вненсения изменений в структры без модификации алгоритмов, работающих с этими структурами. Но делать нужно самому. Само решение не выглядит простым, использует концепты и ненавистную шаблонную магию. Но делается один раз, лежит в отдельном файле и есть не просит. Интересует такое?
--
Справедливость выше закона. А человечность выше справедливости.
Отредактировано 15.12.2024 0:49 rg45 . Предыдущая версия . Еще …
Отредактировано 15.12.2024 0:49 rg45 . Предыдущая версия .
Отредактировано 15.12.2024 0:49 rg45 . Предыдущая версия .
Отредактировано 14.12.2024 22:44 rg45 . Предыдущая версия .
Отредактировано 14.12.2024 22:26 rg45 . Предыдущая версия .
Отредактировано 14.12.2024 22:09 rg45 . Предыдущая версия .
Отредактировано 14.12.2024 22:07 rg45 . Предыдущая версия .
Отредактировано 14.12.2024 22:04 rg45 . Предыдущая версия .
Re[3]: Определение регулярных последовательностей статически
От: kov_serg Россия  
Дата: 14.12.24 23:29
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Ужас. Это вместо того, чтоб уже закопать стюардессу препроцессор...


Ну если я правильно понял вам и нужен ужас. Примерно такой:

[test.cpp]
#include <string>
#include <iostream>

// где-то по коду
static const int z[]={1,2};
static const double x=10;
static const int y[]={1,2,3,4,5,6,7,8,9,10};

// собираем всех кого нужно в древовидную структуру в отдельной единице трансляции маркер имя namespace-а
namespace Consts {
    auto &z=::z;
    namespace Nested {
        auto &x=::x;
        auto &y=::y;
    }
}

// decl
typedef decltype(typeid(0)) ti;
#define DECL(name) decl(ctx,(void*)&name,sizeof(name),#name,typeid(name));
void enum_vars( void (*decl)(void *ctx,void *ptr,size_t size,const char* name,ti t),void *ctx) {
    #include "consts.inc" // что-бы вручную не писать используем готовый код. готовим отдельно
}
#undef DECL

// utils
#include <cxxabi.h>
#include <stdlib.h>
std::string getTypeName(ti t) {
    std::string res; int err=0;
    char* name=abi::__cxa_demangle(t.name(),0,0,&err);
    if (name) { res=name; free(name); }
    return res;
}
void print_var(void *ctx,void *ptr,size_t size,const char* name,ti t) {
    std::cout<<size<<"\t"<<name<<"\t"<<getTypeName(t)<<"\n";
}

int main() {
    enum_vars(print_var,0); // пробегаем по линейному списку (можем делать всё что хотим, например выводим на печать)
    return 0;
}

  build.sh
#!/bin/sh

echo > consts.inc
g++ -c test.cpp && \
objdump -x test.o | c++filt | lua filter.lua > consts.inc && \
rm test.o && \
g++ -o test test.cpp && \
./test
  filter.lua
for line in io.lines() do
    local size,name=line:match"%.data%.rel%.ro%.local%s+(%x+)%s+(Consts::[%w%d:_]+)"
    if name then print("DECL("..name..")") end
end
[output]
8    Consts::z    int [2]
8    Consts::Nested::x    double
40    Consts::Nested::y    int [10]
Отредактировано 15.12.2024 0:05 kov_serg . Предыдущая версия . Еще …
Отредактировано 14.12.2024 23:57 kov_serg . Предыдущая версия .
Отредактировано 14.12.2024 23:51 kov_serg . Предыдущая версия .
Отредактировано 14.12.2024 23:39 kov_serg . Предыдущая версия .
Отредактировано 14.12.2024 23:31 kov_serg . Предыдущая версия .
Re[6]: Определение регулярных последовательностей статически
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 15.12.24 11:55
Оценка:
Здравствуйте, rg45, Вы писали:

R>Зачем нужно обходить эту структуру каким-то парсером?


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

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

R>Есть подход, который позволяет работать с произвольными С++ структурами как с кортежами


Такое я и сам могу сделать, но это опять же потянет за собой изрядный объем двоичного исполняемого кода. Хочется по максимуму обойтись статическими определениями на этапе компиляции.
Re[4]: Определение регулярных последовательностей статически
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 15.12.24 12:00
Оценка:
Здравствуйте, kov_serg, Вы писали:

_>если я правильно понял вам и нужен ужас


Не, ужас не нужен, и тем более не такой. В идеале, меня бы полностью устроила поддержка компилятором формата вроде JSON, из которого он при компиляции тупо складывал бы в память значения/адреса, снабжая каждый элемент кодом типа (значение char/int/float, строка, указатель, список элементов и т.п.) и размером в памяти. Удивительно, что при бешеной популярности JSON, до такого до сих пор не додумались. Оно ж и очень удобно, и в реализации совсем несложно.
Re[7]: Определение регулярных последовательностей статически
От: rg45 СССР  
Дата: 15.12.24 12:01
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

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


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

Я, для большей наглядности, добавил в мой пример пару строчек, чтоб было видно, что вся эта структура вычисляется во время компиляции:

http://coliru.stacked-crooked.com/a/3de810af53ca9426

static_assert(Config.Key_B.Key_X.Value_C == 3.14);
static_assert(Config.Key_B.Key_X.Value_D == "Hello");
--
Справедливость выше закона. А человечность выше справедливости.
Отредактировано 15.12.2024 12:59 rg45 . Предыдущая версия . Еще …
Отредактировано 15.12.2024 12:20 rg45 . Предыдущая версия .
Отредактировано 15.12.2024 12:17 rg45 . Предыдущая версия .
Отредактировано 15.12.2024 12:10 rg45 . Предыдущая версия .
Re[2]: Определение регулярных последовательностей статических данных
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 15.12.24 13:03
Оценка:
Здравствуйте, Nuzhny, Вы писали:

N>А protobuf/flatbuffers не подойдут?


Хотелось бы обойтись без внешних средств.

N>Они внешние, но работают на этапе компиляции. Можно в message запихать любых типов


А как эти тулзы понимают константы/структуры, определенные в C++? Я могу в любом месте указать литерал вида { 7, "abc" } в качестве значения структуры определенного ранее типа?

Вообще, мне только что пришла в голову мысль, что можно попробовать задавать параметры в "реестроподобной" форме. Один хрен почти всегда нужно извлекать какие-то параметры из реестра, имена элементов в коде присутствуют, осталось додумать удобные способы представления структур/массивов. Тогда можно задавать только явно определяемые параметры в виде "ключ/значение", а для разбора вообще сделать универсальный код, берущий данные или из реестра, или из собственной памяти.
Re[8]: Определение регулярных последовательностей статически
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 15.12.24 13:07
Оценка:
Здравствуйте, rg45, Вы писали:

R>Ты, по-видимому, не придал значения ключевым словам "inline constexpr" в моем примере.


Придал, но в Вашем примере все типы и переменные явно именованы. А я хочу как раз избежать этого явного именования, задавая в конфигурации только сами данные, а не определения множества переменных.
Re[9]: Определение регулярных последовательностей статически
От: rg45 СССР  
Дата: 15.12.24 13:11
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

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


Так я же как раз и пытаюсь понять
Автор: rg45
Дата: 14.12 23:23
, почему этого нужно избежать. Что плохого в том, что к компайл-тайм данным будет доступ как по именам, так и по компайл-тайм индексам (как к кортежам)?

Так в моём примере два следующих выражения будут эквивалентны:

Config.Key_B.Key_X.Value_C;
get<2>(get<0>(get<1>(Config)));


Это разве не то, что тебе нужно?
--
Справедливость выше закона. А человечность выше справедливости.
Отредактировано 15.12.2024 13:20 rg45 . Предыдущая версия . Еще …
Отредактировано 15.12.2024 13:17 rg45 . Предыдущая версия .
Отредактировано 15.12.2024 13:16 rg45 . Предыдущая версия .
Отредактировано 15.12.2024 13:16 rg45 . Предыдущая версия .
Отредактировано 15.12.2024 13:13 rg45 . Предыдущая версия .
Отредактировано 15.12.2024 13:12 rg45 . Предыдущая версия .
Отредактировано 15.12.2024 13:11 rg45 . Предыдущая версия .
Re[10]: Определение регулярных последовательностей статически
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 15.12.24 15:31
Оценка:
Здравствуйте, rg45, Вы писали:

R>Что плохого в том, что к компайл-тайм данным будет доступ как по именам, так и по компайл-тайм индексам (как к кортежам)?


Доступа в compile-time мне вообще не нужно — только в run-time. Но Ваш вариант, как я понял, плотно завязан на RTTI, а эта хрень не только тащит лишний код из CRT, но и не умеет работать без плюсовых исключений, а в ядре ни то, ни другое не поддерживается.
Re[12]: Определение регулярных последовательностей статическ
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 15.12.24 19:24
Оценка:
Здравствуйте, rg45, Вы писали:

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


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

R>тут на тебе — RTTI.


Прошу прощения, я попутал Ваш пример с примером от kov_serg, где typeid — промотал не туда. То-то у меня было странное ощущение.

Только как организовать это все в какое-то подобие кортежа, не привлекая std::tuple и ненавистную магию?
Re[5]: Определение регулярных последовательностей статически
От: kov_serg Россия  
Дата: 15.12.24 19:26
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Не, ужас не нужен, и тем более не такой. В идеале, меня бы полностью устроила поддержка компилятором формата вроде JSON, из которого он при компиляции тупо складывал бы в память значения/адреса, снабжая каждый элемент кодом типа (значение char/int/float, строка, указатель, список элементов и т.п.) и размером в памяти. Удивительно, что при бешеной популярности JSON, до такого до сих пор не додумались. Оно ж и очень удобно, и в реализации совсем несложно.


Если бы вы привели конкретный пример было бы проще понять вашу боль
Re[13]: Определение регулярных последовательностей статическ
От: rg45 СССР  
Дата: 15.12.24 19:45
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

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


Ну так я же задавал вопрос
Автор: rg45
Дата: 15.12 00:52
, интересно ли тебе такое решение. Ты ответил
Автор: Евгений Музыченко
Дата: 15.12 14:55
, что такое ты и сам можешь

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

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

Блин, почему почти всё приходится писать по два раза?
--
Справедливость выше закона. А человечность выше справедливости.
Отредактировано 15.12.2024 20:00 rg45 . Предыдущая версия . Еще …
Отредактировано 15.12.2024 20:00 rg45 . Предыдущая версия .
Отредактировано 15.12.2024 19:48 rg45 . Предыдущая версия .
Отредактировано 15.12.2024 19:48 rg45 . Предыдущая версия .
Отредактировано 15.12.2024 19:47 rg45 . Предыдущая версия .
Re[6]: Определение регулярных последовательностей статически
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 15.12.24 19:46
Оценка:
Здравствуйте, 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", "это увеличение вложенности", "это уменьшение вложенности". А известные мне средства организации подобных описаний через шаблонную магию слишком громоздки и корявы, чтоб я мог заставить себя их терпеть.
Re[7]: Определение регулярных последовательностей статически
От: kov_serg Россия  
Дата: 16.12.24 05:40
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>В родном синтаксисе почти все это есть, не хватает сущей мелочи — возможности размещения литеральных значений в "самоопределенном" виде, где каждый элемент снабжается заголовком "это элемент типа 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 — если первый вариант не радует накладными расходами
Отредактировано 16.12.2024 6:56 kov_serg . Предыдущая версия . Еще …
Отредактировано 16.12.2024 6:24 kov_serg . Предыдущая версия .
Отредактировано 16.12.2024 5:53 kov_serg . Предыдущая версия .
Re[8]: Определение регулярных последовательностей статически
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 16.12.24 11:59
Оценка:
Здравствуйте, kov_serg, Вы писали:

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


У Вас получается скомпилировать это с consteval? Мой прошлогодний VC++ отказывается.
Re[15]: Определение регулярных последовательностей статическ
От: rg45 СССР  
Дата: 16.12.24 14:56
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

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


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

А между тем, мой подход, возможно, не прост в реализации, зато даёт как нельзя более простое и естественное использование. Например, рекурсивный обход дерева конфигурационных параметров из этого примера
Автор: 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, который лежит потихоньку в отдельном файле и есть не просит.

Вот теперь и суди, что является извращением, а что нет.
--
Справедливость выше закона. А человечность выше справедливости.
Отредактировано 16.12.2024 16:50 rg45 . Предыдущая версия . Еще …
Отредактировано 16.12.2024 16:13 rg45 . Предыдущая версия .
Отредактировано 16.12.2024 16:11 rg45 . Предыдущая версия .
Отредактировано 16.12.2024 15:58 rg45 . Предыдущая версия .
Отредактировано 16.12.2024 15:57 rg45 . Предыдущая версия .
Отредактировано 16.12.2024 15:52 rg45 . Предыдущая версия .
Отредактировано 16.12.2024 15:51 rg45 . Предыдущая версия .
Отредактировано 16.12.2024 15:44 rg45 . Предыдущая версия .
Отредактировано 16.12.2024 15:43 rg45 . Предыдущая версия .
Отредактировано 16.12.2024 15:41 rg45 . Предыдущая версия .
Отредактировано 16.12.2024 15:38 rg45 . Предыдущая версия .
Отредактировано 16.12.2024 15:36 rg45 . Предыдущая версия .
Отредактировано 16.12.2024 15:34 rg45 . Предыдущая версия .
Отредактировано 16.12.2024 15:32 rg45 . Предыдущая версия .
Отредактировано 16.12.2024 15:20 rg45 . Предыдущая версия .
Re[10]: Определение регулярных последовательностей статически
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 16.12.24 21:56
Оценка:
Здравствуйте, kov_serg, Вы писали:

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


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

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


Во, этот действительно создает в памяти то, что требуется. Спасибо! И работает, начиная с C++11, для меня это важно. Жаль, записей переменной длины не сделать, но это уже не критично, там особо нет смысла экономить память.
Re[16]: Определение регулярных последовательностей статическ
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 16.12.24 22:14
Оценка:
Здравствуйте, rg45, Вы писали:

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


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

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


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

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


Ну вот не получается у меня отключиться от того, что лежит в таких файлах, даже если оно и "есть не просит". Само знание о том, что там лежит идеологически уродливый код, не позволяет мне его использовать спокойно и с удовольствием. Примерно так же было бы неприятно пользоваться вещами, которые заведомо краденые у приличных людей, сильно переживающих потерю. Я очень завидую тем, кто воспринимает шаблонную магию, как высшее достижение, и восхищается ею.
Re[17]: Определение регулярных последовательностей статическ
От: rg45 СССР  
Дата: 16.12.24 22:58
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

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


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


Ну то есть, неприятие сугубо иррациональное. Я тебя понял.
--
Справедливость выше закона. А человечность выше справедливости.
Re[11]: Определение регулярных последовательностей статически
От: kov_serg Россия  
Дата: 17.12.24 07:33
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

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


А что значит записей переменной длинны не сделать?
Re[18]: Определение регулярных последовательностей статическ
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 17.12.24 09:27
Оценка:
Здравствуйте, rg45, Вы писали:

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


Оно как раз исключительно рациональное. Когда требуемые функции реализуются в изолированной библиотеке — мне по барабану, какие трюки там применяются, лишь бы работало надежно, и быстродействие и объем потребной памяти были адекватны функциональности. Пусть хоть трехслойную виртуализацию городят. А когда что-то реализовано на уровне исходного кода, который всегда будет соседствовать с моим, и мои случайные погрешности будут выворачивать наизнанку его потроха — нужны очень серьезные, прямо-таки радикальные выгоды, а таковых эта кухня предоставить не может.
Re[19]: Определение регулярных последовательностей статическ
От: rg45 СССР  
Дата: 17.12.24 09:31
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

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


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


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

А быстродействие и объем памяти, ты приплёл уже лишь бы что-то приплести. Я тебе в этой теме уже несколько раз обосновал, что с этим подходом можно добиться нулевого импакта как по памяти, так и по быстродействию. При самых простых и естественных сценариях использования. Все выгоды налицо, по-моему. Куда уж радикальнее.
--
Справедливость выше закона. А человечность выше справедливости.
Отредактировано 17.12.2024 9:59 rg45 . Предыдущая версия .
Re[13]: Определение регулярных последовательностей статически
От: kov_serg Россия  
Дата: 17.12.24 11:14
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

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


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

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

ps: можно сделать скрипт что бы убрать лишнюю компиляцию и упростить процес
Re[20]: Определение регулярных последовательностей статическ
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 17.12.24 11:19
Оценка:
Здравствуйте, rg45, Вы писали:

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


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

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


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

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


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