Справедливости ради, Antichamber это всё же не многомерие, а неевклидова геометрия, реализованная через склейку порталами. И таки да, я не осилил — после двух часов гуляния по местным вывертам разболелась голова.
Все мои кутешно-плюсатые юкзейсы с асинхронщиной покрывались QFuture + QFutureInterface + собственными темплейтными обмазками, дающими эту (и самодельному подобию Either) типа-монадические интерфейсы.
Не совсем точно выразился. Имеется ввиду любой вызов слота, происходящий асинхронно. А QML предпочитает именно асинхронные вызовы. QFuture это конечно прекрасно, но Qt/QML не рассчитан на его применение повсеместно. Что приведёт к boilerplate везде. Корректное заворачивание нативной логики, чтобы она не обрушила QML engine, тоже требует никак не проверяемого компилятором бойлерплэйта везде. А всего-то надо было добавить хук, позволяющий обернуть место вызова из скриптового движка в нативный код. плюс нормальный сигнал QQmlEngine::exception, вызываемый если скриптовое исключение не было обработано. А не кошмарик QQmlEngine::warnings, перехватывающий вообще всё подряд.
Для несведущих — коду с исключениями недоступные сильные оптимизации. Обсуждается в профильных науч.группах
А поделитесь ссылочкой. Там какая-то фундаментальная проблема с раскруткой стека, отдельным хранилищем для данных или необходимостью RTTI для перехвата?
Страуструп на предложение Саттера по deterministic exceptions ответил в том духе, что не надо городить огород и лучше просто оптимизировать те исключения, что уже есть. Или это ответ в стиле git gud?
С сигналами/слотами Qt'а например тяжело писать последовательный код
Вопрос не в последовательном коде. Вопрос в том, чтобы корректно выловить ошибку, произошедшую в некоем асинхронном вызове, показать её пользователю и продолжить работу дальше. В случае с Qt из слота даже нельзя ничего вернуть. В одном из моих предыдущих проектов исключения вкупе с перегрузкой QCoreApplication::notify позволяли прописать обработку всех необработанных обломов в одном месте. Сейчас сижу на QML, который ни разу не exception-neutral.
как раз эта проблема решаема, т.к. с++ поддерживает много видов обработок ошибок. Вот если бы с++ например не умел в исключения, а вам бы приходилось оборачивать либу какого-нибудь языка которая ими кидается, было бы больнее.
Как раз в этом и состоит проблема. Каждый городит что-то своё. Я не настаиваю на исключениях. Пусть будет какой-нибудь вариант Result'а. Но блин везде. Унифицированно. А не так, что "здесь играем, здесь не играем, здесь рыбу заворачивали".
Касательно другого языка — с высокой вероятностью вам придётся писать клей, даже если и там, и там исключения. Потому что если даже и там, и там они нативные, никто не даёт гарантию, что они совместимые. Даже если и там, и там под капотом SEH.
Спасибо за ответ. Последний пункт огорчает. Вспоминаются неоднократные новости о падении сервисов (гугл как раз на днях) или вообще полном закрытии, после чего устройство превращается в "кирпич". Было бы очень полезно на всякий непредвиденный случай иметь опцию управления с телефона напрямую через Bluetooth или при нахождении в одной подсети. Конечно, уведомления работать не будут в любом случае, но КМК уведомления — скорее приятный бонус чем обязательный функционал.
Может я пропустил, но не увидел ответа на один животрепещущий вопрос. Что будет, если обслуживающий веб-сервис ляжет либо будет недоступен по тем или иным причинам? Превратятся ли гаджеты в "кирпич"? Продолжат ли работать по вбитой ранее программе? Будет ли владельцу уведомление на телефон о недоступности? Есть ли возможность настраивать без наличия доступа к сервису вообще?
Он вроде немного не про то. Я не уверен, что интерфейс какой-нибудь user32.dll можно будет записать в виде WASM-файла, не создавая лишних прокладок. Если вы про инициативу WASI, она про создание и стандартизацию некоего аналога POSIX, доступного на любой не-браузерной реализации WASM.
исключения — всего лишь один из инструментов с++, пользоваться ими никто не заставляет
За исключением того, что хороший кусок стандартной библиотеки завязан на использование исключений для оповещения об ошибках. ЕМНИП стандарт вообще не предусматривает работу с отключенными исключениями.
Как пример, мы теперь имеем двойные интерфейсы в std::filesystem, причём некоторые методы, возвращающие статус через std::error_code (std::filesystem::directory_iterator::increment), всё равно кидаются исключениями.
А ещё кроме исключений у нас есть std::error_code, пропозалы на std::outcome, std::expected и deterministic exceptions Саттера, и дичайший зоопарк методов регистрации, эскалации и обработки ошибок в разных фреймворках (Qt, ау!).
Короче, с С++ будет проблема — на каком именно диалекте вы хотите писать? И не дай бог ваш диалект не совпадёт с диалектом закрытой либы за много чемоданов денег, которую вам кров из носу надо использовать...
Если вы не хотите видеть GC в системе типов, вы будете всё равно включать его глобально. Причём такой "глобальный включатель" будет срабатывать при наличии хотя бы одного модуля, требующего GC. С принудительными сканами всего и вся и всё равно проблемами, когда кто-то будет случайно руками удалять управляемый объект.
Если же вы хотите выделить сборку мусора в отдельный тип smart pointer'a, у вас будут проблемы с просачиванием его везде, включая сигнатуры методов, поля структур и т.п. Плюс — корни GC будут у вас отдельным типом. Который надо будет аккуратно раскладывать на стек.
Пока что приемлемый сценарий, который я вижу — локальное отключение GC для некоторых значений или типов.
Я в общем-то согласен с тезисом про границы применимости и инструменты для системщиков. Жил бы С только как кроссплатформенный ассемблер — не было бы проблем.
Однако для меня как прикладиника основную головную боль представляет именно просачивание С туда, где не совсем хочется его видеть. И начинается всё тут с C interface для большого количества чисто прикладных библиотек. И вообще использования С как lingua franca.
К примеру, заголовочные файлы. Почти всегда с макро-константами. Иногда с "особо альтернативными" макро-константами или вообще кусками кода, засунутыми в макросы. Вроде первичной инициализации структур. Если нужно сделать из этого богатства биндинги для чего-то, не являющегося С или С++, приходится либо искать генератор, умеющий такое парсить, или писать руками. Особенно весело для больших библиотек с заголовочными файлами на несколько тысяч строк.
Связанная проблема — макро-константы для условной компиляции. Опять же, решение или надо тщательно искать (если вообще есть), или писать руками.
Ещё одна связанная проблема — зоопарк целочисленных типов. Fixed-width integers появились только в C99.
Короче говоря, я хотел бы видеть в качестве языка описания бинарных интерфейсов что-то более строго типизированное и без макросов.
К сожалению, все подобные статьи почему-то напоминают старую шутку про рисование совы. Рассматриваются только примитивнейшие случаи. Не рассматриваются ситуации, когда модель данных представляет собой хотя бы иерархию объектов, с возможностью эти самые объекты переместить в иерархии или вообще удалить. А когда появляются невладеющие ссылки внутри иерархии, "команда" (а конкретно возможность отката изменений) вообще сыпется. Реализация каждой команды требует нетривиального кода, учитывающего все нетривиальные внутренние особенности объектов в частности и модели данных вообще.
Не совсем понял. Если человек не знает, что у него может быть припадок, он такое предупреждение просто пропустит — и схлопочет припадок. Даже если предупреждение в самом начале игры большими буквами.
Я не в курсе, есть ли альтернатива. Самой Ангары фактически нет. Нет в том плане, что был один пуск лёгкой и один тяжёлой. А потом тишина. И море обещаний и планов, которые, как сами видите, сдвигались уже не раз и не два. Как по мне, будет какой-то разговор, когда произведут хотя бы два запуска.
Применительно к украинскому, я был бы весьма рад если бы Ґ выкинули на мороз. Применяется в двух десятках слов, при этом из-за неё переконопатили транслитерацию.
Справедливости ради, Antichamber это всё же не многомерие, а неевклидова геометрия, реализованная через склейку порталами. И таки да, я не осилил — после двух часов гуляния по местным вывертам разболелась голова.
Совет номер ноль. Вставляйте цитаты текстом. Потому что заставлять читать мыльную картинку с телефона — проявлять верх неуважения.
Не совсем точно выразился. Имеется ввиду любой вызов слота, происходящий асинхронно. А QML предпочитает именно асинхронные вызовы. QFuture это конечно прекрасно, но Qt/QML не рассчитан на его применение повсеместно. Что приведёт к boilerplate везде. Корректное заворачивание нативной логики, чтобы она не обрушила QML engine, тоже требует никак не проверяемого компилятором бойлерплэйта везде. А всего-то надо было добавить хук, позволяющий обернуть место вызова из скриптового движка в нативный код. плюс нормальный сигнал
QQmlEngine::exception, вызываемый если скриптовое исключение не было обработано. А не кошмарикQQmlEngine::warnings, перехватывающий вообще всё подряд.Интересно, спасибо. Про множество landing pad'ов не нашёл пока. Интересно, нельзя ли генерировать всегда один, с набором флагов внутри что чистить.
А поделитесь ссылочкой. Там какая-то фундаментальная проблема с раскруткой стека, отдельным хранилищем для данных или необходимостью RTTI для перехвата?
Страуструп на предложение Саттера по deterministic exceptions ответил в том духе, что не надо городить огород и лучше просто оптимизировать те исключения, что уже есть. Или это ответ в стиле git gud?
Вопрос не в последовательном коде. Вопрос в том, чтобы корректно выловить ошибку, произошедшую в некоем асинхронном вызове, показать её пользователю и продолжить работу дальше. В случае с Qt из слота даже нельзя ничего вернуть. В одном из моих предыдущих проектов исключения вкупе с перегрузкой
QCoreApplication::notifyпозволяли прописать обработку всех необработанных обломов в одном месте. Сейчас сижу на QML, который ни разу не exception-neutral.Как раз в этом и состоит проблема. Каждый городит что-то своё. Я не настаиваю на исключениях. Пусть будет какой-нибудь вариант Result'а. Но блин везде. Унифицированно. А не так, что "здесь играем, здесь не играем, здесь рыбу заворачивали".
Касательно другого языка — с высокой вероятностью вам придётся писать клей, даже если и там, и там исключения. Потому что если даже и там, и там они нативные, никто не даёт гарантию, что они совместимые. Даже если и там, и там под капотом SEH.
Спасибо за ответ. Последний пункт огорчает. Вспоминаются неоднократные новости о падении сервисов (гугл как раз на днях) или вообще полном закрытии, после чего устройство превращается в "кирпич". Было бы очень полезно на всякий непредвиденный случай иметь опцию управления с телефона напрямую через Bluetooth или при нахождении в одной подсети. Конечно, уведомления работать не будут в любом случае, но КМК уведомления — скорее приятный бонус чем обязательный функционал.
Может я пропустил, но не увидел ответа на один животрепещущий вопрос. Что будет, если обслуживающий веб-сервис ляжет либо будет недоступен по тем или иным причинам? Превратятся ли гаджеты в "кирпич"? Продолжат ли работать по вбитой ранее программе? Будет ли владельцу уведомление на телефон о недоступности? Есть ли возможность настраивать без наличия доступа к сервису вообще?
Он вроде немного не про то. Я не уверен, что интерфейс какой-нибудь user32.dll можно будет записать в виде WASM-файла, не создавая лишних прокладок. Если вы про инициативу WASI, она про создание и стандартизацию некоего аналога POSIX, доступного на любой не-браузерной реализации WASM.
За исключением того, что хороший кусок стандартной библиотеки завязан на использование исключений для оповещения об ошибках. ЕМНИП стандарт вообще не предусматривает работу с отключенными исключениями.
Как пример, мы теперь имеем двойные интерфейсы в
std::filesystem, причём некоторые методы, возвращающие статус черезstd::error_code(std::filesystem::directory_iterator::increment), всё равно кидаются исключениями.А ещё кроме исключений у нас есть
std::error_code, пропозалы наstd::outcome,std::expectedи deterministic exceptions Саттера, и дичайший зоопарк методов регистрации, эскалации и обработки ошибок в разных фреймворках (Qt, ау!).Короче, с С++ будет проблема — на каком именно диалекте вы хотите писать? И не дай бог ваш диалект не совпадёт с диалектом закрытой либы за много чемоданов денег, которую вам кров из носу надо использовать...
ИМХО сборщик мусора — слишком инвазивная вещь.
Если вы не хотите видеть GC в системе типов, вы будете всё равно включать его глобально. Причём такой "глобальный включатель" будет срабатывать при наличии хотя бы одного модуля, требующего GC. С принудительными сканами всего и вся и всё равно проблемами, когда кто-то будет случайно руками удалять управляемый объект.
Если же вы хотите выделить сборку мусора в отдельный тип smart pointer'a, у вас будут проблемы с просачиванием его везде, включая сигнатуры методов, поля структур и т.п. Плюс — корни GC будут у вас отдельным типом. Который надо будет аккуратно раскладывать на стек.
Пока что приемлемый сценарий, который я вижу — локальное отключение GC для некоторых значений или типов.
Проверки времени жизни существуют только на этапе компиляции. А если вам нужно убрать проверку на выход за границы массива, всегда есть get_unchecked.
Это то самое "я лучше знаю, что делаю", только выраженное явно.
Я в общем-то согласен с тезисом про границы применимости и инструменты для системщиков. Жил бы С только как кроссплатформенный ассемблер — не было бы проблем.
Однако для меня как прикладиника основную головную боль представляет именно просачивание С туда, где не совсем хочется его видеть. И начинается всё тут с C interface для большого количества чисто прикладных библиотек. И вообще использования С как lingua franca.
К примеру, заголовочные файлы. Почти всегда с макро-константами. Иногда с "особо альтернативными" макро-константами или вообще кусками кода, засунутыми в макросы. Вроде первичной инициализации структур. Если нужно сделать из этого богатства биндинги для чего-то, не являющегося С или С++, приходится либо искать генератор, умеющий такое парсить, или писать руками. Особенно весело для больших библиотек с заголовочными файлами на несколько тысяч строк.
Связанная проблема — макро-константы для условной компиляции. Опять же, решение или надо тщательно искать (если вообще есть), или писать руками.
Ещё одна связанная проблема — зоопарк целочисленных типов. Fixed-width integers появились только в C99.
Короче говоря, я хотел бы видеть в качестве языка описания бинарных интерфейсов что-то более строго типизированное и без макросов.
К сожалению, все подобные статьи почему-то напоминают старую шутку про рисование совы. Рассматриваются только примитивнейшие случаи. Не рассматриваются ситуации, когда модель данных представляет собой хотя бы иерархию объектов, с возможностью эти самые объекты переместить в иерархии или вообще удалить. А когда появляются невладеющие ссылки внутри иерархии, "команда" (а конкретно возможность отката изменений) вообще сыпется. Реализация каждой команды требует нетривиального кода, учитывающего все нетривиальные внутренние особенности объектов в частности и модели данных вообще.
Не совсем понял. Если человек не знает, что у него может быть припадок, он такое предупреждение просто пропустит — и схлопочет припадок. Даже если предупреждение в самом начале игры большими буквами.
Для меня как дилетанта это будет означать, что Ангару таки производят, а не запустили последнюю оставшуюся, сделанную ещё в первой половине 10х.
Может быть, не в курсе. С этим постулатом я спорить не собираюсь.
То ли 15, то ли 20 лет (смотря как считать) доводят. Маск, напоминаю, за сравнимое время наладил регулярные пуски многоразовых ракет.
Андрей Батутыч, что ли? Извините, этому балаболу доверия никакого. Пусть сначала сделает.
Я не в курсе, есть ли альтернатива. Самой Ангары фактически нет. Нет в том плане, что был один пуск лёгкой и один тяжёлой. А потом тишина. И море обещаний и планов, которые, как сами видите, сдвигались уже не раз и не два. Как по мне, будет какой-то разговор, когда произведут хотя бы два запуска.
Боюсь, есть третий вариант. С грехом пополам запустят последнюю ракету (если вообще запустят), после чего проект окончательно заглохнет.
Хотелось бы увидеть результаты работы с этим тулом у самих майков.
Применительно к украинскому, я был бы весьма рад если бы Ґ выкинули на мороз. Применяется в двух десятках слов, при этом из-за неё переконопатили транслитерацию.