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

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

S>>А кстати как корректно узнать, что они отключены у компилятора? (Вопрос 3)

C>См. макрос __cpp_exceptions, (он должен быть в С++20).

Спасибо, это подойдёт.
Не нашёл правда инфу о нём на cppref

C>Но лучше, пусть пользователь явно скажет системе сборки хочет он бросание исключений данной библиотекой или нет.

Я и хочу сделать полиси классы отдельно (с исключениями и без)
С исключениями оберну в #ifdef __cpp_exceptions

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

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

Возвращать лишнее при throw_policy тоже как-то некрасиво.

По сути возвращаемого значения может и не быть.
А смарт поинтер класс (RAII), который в конструкторе запрашивает память.
В случае неудачи хранит nullptr, а от полиси зависит будет ли исключение из конструктора брошено.

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

Собственно инициализация вызывается только один раз, сразу на все любые типы, но для каждой dll/exe отдельно

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

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

S>>А кстати как корректно узнать, что они отключены у компилятора? (Вопрос 3)

C>См. макрос __cpp_exceptions, (он должен быть в С++20).

Спасибо, это подойдёт.
Не нашёл правда инфу о нём на cppref

C>Но лучше, пусть пользователь явно скажет системе сборки хочет он бросание исключений данной библиотекой или нет.

Я и хочу сделать полиси классы отдельно (с исключениями и без)
Классы с исключениями оберну в #ifdef __cpp_exceptions, чтобы их вообще не было в этом случае

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

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

Возвращать лишнее при throw_policy тоже как-то некрасиво.

По сути возвращаемого значения может и не быть.
А смарт поинтер класс (RAII), который в конструкторе запрашивает память.
В случае неудачи хранит nullptr, а от полиси зависит будет ли исключение из конструктора брошено.

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

Собственно инициализация вызывается только один раз, сразу на все любые типы, но для каждой dll/exe отдельно