> set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED ON) Стоит

Да и у меня там auto, он бы начал ругаться

ну это делается для того, чтобы это перечисление было общее у readFile readString writeFile writeString

заметь, что readString может бросить ошибку перекодировки

-lcurl (только это) cmake . make

https://pastebin.com/NQAazYAT

Вот так главный выглядит

смотри, если я сделаю _разные стандартные_ коллбеки для броска эксепшена из функций loadFile/loadString/..., то их кто-то когда-то перепутает

https://pastebin.com/NQAazYAT

> set(namesource_files main.cpp) В исходном все впорядке, просто редактировал только что...

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

Да На Json.cpp орет

и параметр на самом деле был exception_thrower<ExceptionType😠)

В главном не достаточно?)

Да, не достаточно

Спасибо

хм... а между прочим, в каком-то смысле это круто

Роскомнадзор в чате, все в машину!

Ты участвовал в промышленной разработке? В продакшене программа упадет

Просто к тому, что тут правило "сами дураки" звучит как-то очень странно

Мне пока определенно нравится идея с коллбеком, который либо принимает function либо унифицированное имя через extension point, и я ушел в размышления над этим. Там вроде аккуратно получится подпихать унифицированные реализации

Я имею в виду конечно сущность с кодовым названием customizable_error_handler

Просто с точки зрения интерфейса это void () (exact_error_info const&)

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

Как GoF расшифровывается?

Gang of Four

А, понял)

@AlexFails ↑

Хм... кажется мои мысли сошлись. С точки зрения вызывающего сигнатура функции содержит builder, с точки зрения функции содержит function

Надо просто совместить? :)

У меня есть минивелосипед, жду в стандарте

К чему? Про optional я знаю. Про builder+function фишка в том, что вызывающий хочет на самом деле передать builder, который в нужный момент сделает function, который будет вызван. Синтаксис с перечислением стандартного действия при ошибке на самом деле именно это

`Class Foo { private: int a; int b; } Foo::Foo(): a , b `

вопрос

почему в конструкторе писать в том порядке

что и в классе

?

почему в конструкторе писать в том порядке

Потому что конструктору пофигу на порядок списка инициализации

Потому что конструктору пофигу на порядок списка инициализации

это я понимаю, но можно ли в конструкторе написать наоборот?

это я понимаю, но можно ли в конструкторе написать наоборот?

Нет, потому что порядок создания и удаления определяется порядком переменных в классе

спс друг мой

это я понимаю, но можно ли в конструкторе написать наоборот?

В смысле написать можно, но за такое бьют по рукам

понял, понял

А, туплю

Ого! Хорошо что я не кроссплат пишу)))

довольно плохо

хотя бы потому что чертов препроцессор сильно замедлил принятие модулей

ну и всякие https://github.com/boostorg/config/blob/develop/include/boost/config/compiler/borland.hpp которые по хорошему должны парой директив заменяться типа __has_feature

в корневом cmakelists.txt сделать include_directories(.)

есть еще CMAKE_SOURCE_PATH и CMAKE_CURRENT_SOURCE_PATH

соответственно корневой каталог сорцов и текущий

лучше их использовать

ага

@berkus я тебя простил :)

ну и всякие https://github.com/boostorg/config/blob/develop/include/boost/config/compiler/borland.hpp которые по хорошему должны парой директив заменяться типа __has_feature

Борланд компилер еще жив?

нет

статик либы это просто obj файлы в конвертике

посмотри на командную строку, ничего там не прилинковывается

если cmake современный то эти target_link_libraries будут использоваться при линковке экзешника с твоей либой

либа естественно соберется, она же не резолвит ничего

потому что динамическая библиотека это экзешник и ее линковать надо соответственно

я написал сообщением выше

если cmake современный то эти target_link_libraries будут использоваться при линковке экзешника с твоей либой

ну посмотри на что undefined reference и проверь что оно действительно прилинковывается. circular deps на линуксе это беда

два раза либу укажи

Господа, а инициализация union-ов по-типу union_type x{.field=42};это стандартный синтаксис, или какое-то загнутое расширение?

точка странная какая-то

инициализация похожа на правду

а вот точка

без точки очевидно не соберется

С99 вроде

https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html

С99 вроде

а разве не расширение gnu99?

а разве не расширение gnu99?

По ссылке написано, что это C99.

обсуждали здесь, вроде собирались в с++20 ввести такой синтаксис

designated initializers

Можно

надеюсь что нет

все равно не доживешь, наверное

Господа, ни у кого не завалялся хороший сборник вопросов для собеседования?