Разве это не std::optional. Так же стоит указать, что optional, variant, any и string_view(string_ref) давно есть в boost, так что можно не ждать 17-го стандарта, а уже использовать.
Я в курсе, что такое std::async. И если быть точным, то она не всегда создает новый поток. Во-первых в зависимости от дефолтной политики результат может быть получен вообще синхронно. Во-вторых, в зависимости от имплементации асинхронная версия может либо создавать новый поток, либо использовать пул потоков.
За наводку на https://tokio.rs/ — спасибо.
Начал разбираться с растом, и удивился и порадовался его продуманности во многих вещах — контроль времени жизни ссылок, невозможность использовать после move, функциональные возможности. Но очень расстраивает отсутствие корутин и N:M-параллелизма. Даже аналога обычного C++-ного std::async нет из коробки, да и futures какие-то странные. Мне кажется, что если бы это было, то rust мог бы серьезно побороться за нишу серверныз приложений, а пока шансов, увы, немного.
Насколько я понял, была годная реализация корутин, но она оказалась несовместимой со стандартной библиотекой из-за того, что последняя активно использует TLS. И на данный момент корутины в принципе не в приоритете. Было бы хорошо, если бы кто-то внес уточнения, вдруг я что-то упустил.
Очень правильный вопрос. На данный момент — как удаление и вставку в другом месте. Это не совсем правильно с точки зрения совместной работы: если один человек переместил узел, а второй одновременно поменял его свойства или отредактировал его дочерний элемент, то в результате трансформаций правки второго пропадут.
Если индекс в коллекции делать атрибутом элемента или всей коллекции, то встает вопрос о поддержании корректности индексов — чтобы в результате совместного редактирования индексы не дублировались.
Хорошим решением проблемы мне видится добавление отдельной операции — перемещения в дополнении ко вставке и удалению (и еще нескольким другим, о которых я не написал в этой части).
Мой комментарий был о том, что практически всегда можно оставить один из вариантов, в зависимости от использования данных внутри функции — либо передавать по значению, если внутри метода сохраняются данные, либо передавать по константной ссылке. И не нужно большого числа перегрузок.
Все-таки перегрузки с const std::string&& бессмысленны. Достаточно иметь 2 перегрузки — const std::string& и std::string&&. Однако, если речь идет о сеттере, внутри которого значение захватывается по значению, то при наличии rvalue-ссылок можно передавать просто по значению:
1.10. Не используйте vector там, где можно было бы обойтись list или deque
Для современных декстопов не очень актуальный совет, за счет последовательного расположения в памяти вектор, даже с учетом изменений может быть быстре листа: Тыц
Я совсем не понимаю, в чем проблема с реализацией async/await для всякой экзотики. Будет точно так же, как уже есть для std::async — если платформа не позволяет, то код будет просто синхронным.
Ну если миллиарды устройств и пользователей это для вас «никуда» — тогда да, наверное.
Если верить статистике доля Windows на рынке декстопов порядка 90%, давайте поддерживать только ее, ведь это "миллиарды устройств и пользователей".
И? Код можно собрать и под PDP-10 и под C64.
Собирается и успешно работает.
двух с половиной разработчиков
мертворождённое творение типа Emscripten'а
Приятно говорить с объективным человеком, не склонным к холивару.
чтобы ради неё корёжить стандарты
Пользователи других языков с async/await не считают, что их языки покорежили. Поддержка таких вещей как асинхронность, рефлексия и прочее без помощи рантайма никогда не будет эффективной, и рано или поздно появится.
В любом случае поддержать их можно — было бы желание.
Поддержать на уровне буста? То есть вместо того, чтобы поддерживать на уровне рантайма и компилятора будем для каждой пары компилятор-платформа добавлять что-то в буст? Как по мне это путь в никуда.
А на этих «экзотических платформах» реально кто-то что-то пишет?
Представьте себе да. Точнее это одна из платформ, под которую собирается код.
И кто, собственно, помешает вам реализовать поддержку соответствующий абстракций для них? Тот же Emscripten эмулирует всё на свете поверх одного массива — совершенно непонятно что может помешать реализовать Boost.Context для него.
… Используя сакральное знание о деталях реализации Emscripten. И если вдруг подход поменяется (например, в сторону JS objects как у альтернатив), то внезапно все перестанет работать. Собственно в этом и есть главный изъян подхода, когда библиотека берет на себя platform-specific вещи.
Не могу не согласиться, что реализации на основе Boost.Context мягко говоря имеют не меньшее количество проблем.
1) Про платформенно-зависимость было упомянуто. Список поддерживаемых архитектур довольно скуден. Сохранение стэка с регистрами никогда не заработает для экзотических платформ, типа Emscripten (компиляция C++ в asm.js).
2) Boost.Context не решает проблему "параллельности" стандартной библиотеки.
Вот есть подборка по редактирования офисных документов. Но скажу честно, что опыта установки ничего из этого нет. Если формат конкретно офисных документов не принципиален, то стоит посмотреть в сторону Apache Wave (бывший Google Wave).
Самое простое и эффективное решение FalseTie на мой взгляд.
У OT в оффлайне нарастает сложность задачи merge нетривиальным образом. Вы тестировали такие сценарии?
Из того, что проверяли в ручном режиме задержки именно OT-движка были незаметны. Специализированных тестов пока нет, у нас еще есть много моментов для оптимизаций и сжатия операций.
Подход с гуидами близок к упоминавшемуся выше в комментариях CRDT. Если гуиды присваивать всему вплоть до букв, то это сильно просаживает производительность и увеличивает размер документа. Если внутри абзаца гуидов нет, то сама структура документа мержится однозначно, а вот текст внутри параграфов с теми же проблемами, что и плоский текст. Хотя в целом, если выбрать в качестве метода синхронизации мерж, то это решение выглядело бы оптимальным.
По поводу «аптеки» и «оптики» — для классического OT будет, естественно гибрид, хотя отслеживать такие конфликты возможность есть. Но и в зависимости от правил мержа это тоже может быть автоматически смержено, либо помечено как конфликт.
Проблема в том, что алгоритм автоматического мержа вынужден выбирать между надежностью и удобством для пользователя. То есть либо мы выбираем надежный алгоритм, который будет чаще просить пользователя смержить вручную. Либо более интеллектуальный, но который может дать неверный результат. По сравнению с простым текстом сложность мержа полноценного документа больше: представьте, что один пользователь добавил несколько строк в таблицу, а другой несколько столбцов. И при этом они отредактировали содержимое нескольких ячеек.
Кроме того, интерфейс ручного мержа офисных документов не может быть проще чем существующие утилиты для 3-way мержа. Вероятнее всего он будет значительно сложнее, а это значит, что пользователей нужно научить с ним работать.
1. Для каждого документа хранится вся история трансформаций (много весят, выборки тормозят и тп)
Скорее всего имелись ввиду операции, поскольку трансформации — это методы.
Правильно замечено, что наборы операций можно мержить. Плюс историю старше определенного времени можно удалять, если предположить, что клиенты достаточно регулярно синхронизируются с сервером. К тому же вся история нужна только на сервере, и при правильном выборе алгоритма большая ее часть практически не используется и может быть заархивирована. То есть проблемы с размером истории чисто технические и легко решаются с помощью стандартных подходов.
Малейший баг в алгоритме (а алгоритмы тут довольно нетривиальные) легко может запороть документ
Да, алгоритм должен быть качественно оттестирован. Кроме того, счет наличия истории всегда можно откатиться к последнему валидному состоянию.
Для получения актуальной версии нужно плясать с бубном
Обычно актуальная версия как раз и хранится, поэтому доступна без дополнительных издержек. Если нужно быстро получать старые версии, то можно использовать чекпоинты.
Хранить нужно лишь последнюю актуальную версию и применять к ней патчи от клиентов.
В этом как раз основная разница между ОТ и мержем. OT работает с операциями и имеет информацию о том, как менялся документ. Мерж имеет дело только с конечными состояниями и уже постфактум находит одинаковые и отличающиеся части, что дает намного меньше возможности «свести» различные изменения пользователей.
За наводку на https://tokio.rs/ — спасибо.
Насколько я понял, была годная реализация корутин, но она оказалась несовместимой со стандартной библиотекой из-за того, что последняя активно использует TLS. И на данный момент корутины в принципе не в приоритете. Было бы хорошо, если бы кто-то внес уточнения, вдруг я что-то упустил.
Если индекс в коллекции делать атрибутом элемента или всей коллекции, то встает вопрос о поддержании корректности индексов — чтобы в результате совместного редактирования индексы не дублировались.
Хорошим решением проблемы мне видится добавление отдельной операции — перемещения в дополнении ко вставке и удалению (и еще нескольким другим, о которых я не написал в этой части).
Поскольку move очень дешев, то это будет практически оптимально для всех случаев:
Вывод: нет однозначно лучшего контейнера, даже с учетом операций вставки в произвольное место.
Для современных декстопов не очень актуальный совет, за счет последовательного расположения в памяти вектор, даже с учетом изменений может быть быстре листа: Тыц
Если верить статистике доля Windows на рынке декстопов порядка 90%, давайте поддерживать только ее, ведь это "миллиарды устройств и пользователей".
Собирается и успешно работает.
Приятно говорить с объективным человеком, не склонным к холивару.
Пользователи других языков с async/await не считают, что их языки покорежили. Поддержка таких вещей как асинхронность, рефлексия и прочее без помощи рантайма никогда не будет эффективной, и рано или поздно появится.
Поддержать на уровне буста? То есть вместо того, чтобы поддерживать на уровне рантайма и компилятора будем для каждой пары компилятор-платформа добавлять что-то в буст? Как по мне это путь в никуда.
Представьте себе да. Точнее это одна из платформ, под которую собирается код.
… Используя сакральное знание о деталях реализации Emscripten. И если вдруг подход поменяется (например, в сторону JS objects как у альтернатив), то внезапно все перестанет работать. Собственно в этом и есть главный изъян подхода, когда библиотека берет на себя platform-specific вещи.
1) Про платформенно-зависимость было упомянуто. Список поддерживаемых архитектур довольно скуден. Сохранение стэка с регистрами никогда не заработает для экзотических платформ, типа Emscripten (компиляция C++ в asm.js).
2) Boost.Context не решает проблему "параллельности" стандартной библиотеки.
Самое простое и эффективное решение FalseTie на мой взгляд.
Из того, что проверяли в ручном режиме задержки именно OT-движка были незаметны. Специализированных тестов пока нет, у нас еще есть много моментов для оптимизаций и сжатия операций.
По поводу «аптеки» и «оптики» — для классического OT будет, естественно гибрид, хотя отслеживать такие конфликты возможность есть. Но и в зависимости от правил мержа это тоже может быть автоматически смержено, либо помечено как конфликт.
Проблема в том, что алгоритм автоматического мержа вынужден выбирать между надежностью и удобством для пользователя. То есть либо мы выбираем надежный алгоритм, который будет чаще просить пользователя смержить вручную. Либо более интеллектуальный, но который может дать неверный результат. По сравнению с простым текстом сложность мержа полноценного документа больше: представьте, что один пользователь добавил несколько строк в таблицу, а другой несколько столбцов. И при этом они отредактировали содержимое нескольких ячеек.
Кроме того, интерфейс ручного мержа офисных документов не может быть проще чем существующие утилиты для 3-way мержа. Вероятнее всего он будет значительно сложнее, а это значит, что пользователей нужно научить с ним работать.
Скорее всего имелись ввиду операции, поскольку трансформации — это методы.
Правильно замечено, что наборы операций можно мержить. Плюс историю старше определенного времени можно удалять, если предположить, что клиенты достаточно регулярно синхронизируются с сервером. К тому же вся история нужна только на сервере, и при правильном выборе алгоритма большая ее часть практически не используется и может быть заархивирована. То есть проблемы с размером истории чисто технические и легко решаются с помощью стандартных подходов.
Да, алгоритм должен быть качественно оттестирован. Кроме того, счет наличия истории всегда можно откатиться к последнему валидному состоянию.
Обычно актуальная версия как раз и хранится, поэтому доступна без дополнительных издержек. Если нужно быстро получать старые версии, то можно использовать чекпоинты.
В этом как раз основная разница между ОТ и мержем. OT работает с операциями и имеет информацию о том, как менялся документ. Мерж имеет дело только с конечными состояниями и уже постфактум находит одинаковые и отличающиеся части, что дает намного меньше возможности «свести» различные изменения пользователей.