Как стать автором
Обновить
35
Карма
0
Рейтинг
Дмитрий @GraD_Kh

C++ Enginner

Rust: состояния типов

Я думаю, что не только мне интересно, как выглядели состояния типов изначально. Можно какие ссылки?

Типы struct, union и enum в Modern C++

Разве это не std::optional. Так же стоит указать, что optional, variant, any и string_view(string_ref) давно есть в boost, так что можно не ждать 17-го стандарта, а уже использовать.

Выпуск Rust 1.17

Да, похоже, что thread pool не используется. Я был сбит с толку этой темой. Причем похоже не используется как раз из-за потенциальных проблем с TLS.

Выпуск Rust 1.17

Я в курсе, что такое std::async. И если быть точным, то она не всегда создает новый поток. Во-первых в зависимости от дефолтной политики результат может быть получен вообще синхронно. Во-вторых, в зависимости от имплементации асинхронная версия может либо создавать новый поток, либо использовать пул потоков.
За наводку на https://tokio.rs/ — спасибо.

Выпуск Rust 1.17

Начал разбираться с растом, и удивился и порадовался его продуманности во многих вещах — контроль времени жизни ссылок, невозможность использовать после move, функциональные возможности. Но очень расстраивает отсутствие корутин и N:M-параллелизма. Даже аналога обычного C++-ного std::async нет из коробки, да и futures какие-то странные. Мне кажется, что если бы это было, то rust мог бы серьезно побороться за нишу серверныз приложений, а пока шансов, увы, немного.
Насколько я понял, была годная реализация корутин, но она оказалась несовместимой со стандартной библиотекой из-за того, что последняя активно использует TLS. И на данный момент корутины в принципе не в приоритете. Было бы хорошо, если бы кто-то внес уточнения, вдруг я что-то упустил.

Совместное редактирование. Часть 2

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

Последние новости о развитии C++

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

Последние новости о развитии C++

Все-таки перегрузки с const std::string&& бессмысленны. Достаточно иметь 2 перегрузки — const std::string& и std::string&&. Однако, если речь идет о сеттере, внутри которого значение захватывается по значению, то при наличии rvalue-ссылок можно передавать просто по значению:
void SomeClass::SetName(std::string first, std::string last)
{
    _first = std::move(first);
    _last = std::move(last);
}

Поскольку move очень дешев, то это будет практически оптимально для всех случаев:
foo->setName(first, last);
foo->setName(std::move(first), std::move(last));
foo->setName("Ivan", "Pupkin");

Немного размышлений и советов по оптимизации кода на С++

Все зависит от конкретных цифр и надо не гадать, а делать бенчмарки: http://baptiste-wicht.com/posts/2012/12/cpp-benchmark-vector-list-deque.html
Вывод: нет однозначно лучшего контейнера, даже с учетом операций вставки в произвольное место.

Немного размышлений и советов по оптимизации кода на С++

1.10. Не используйте vector там, где можно было бы обойтись list или deque

Для современных декстопов не очень актуальный совет, за счет последовательного расположения в памяти вектор, даже с учетом изменений может быть быстре листа: Тыц

Возражения против принятия Coroutines с await в C++17

Я совсем не понимаю, в чем проблема с реализацией async/await для всякой экзотики. Будет точно так же, как уже есть для std::async — если платформа не позволяет, то код будет просто синхронным.

Возражения против принятия Coroutines с await в C++17

Ну если миллиарды устройств и пользователей это для вас «никуда» — тогда да, наверное.

Если верить статистике доля Windows на рынке декстопов порядка 90%, давайте поддерживать только ее, ведь это "миллиарды устройств и пользователей".

И? Код можно собрать и под PDP-10 и под C64.

Собирается и успешно работает.

двух с половиной разработчиков

мертворождённое творение типа Emscripten'а

Приятно говорить с объективным человеком, не склонным к холивару.

чтобы ради неё корёжить стандарты

Пользователи других языков с async/await не считают, что их языки покорежили. Поддержка таких вещей как асинхронность, рефлексия и прочее без помощи рантайма никогда не будет эффективной, и рано или поздно появится.

Возражения против принятия Coroutines с await в C++17

В любом случае поддержать их можно — было бы желание.

Поддержать на уровне буста? То есть вместо того, чтобы поддерживать на уровне рантайма и компилятора будем для каждой пары компилятор-платформа добавлять что-то в буст? Как по мне это путь в никуда.

А на этих «экзотических платформах» реально кто-то что-то пишет?

Представьте себе да. Точнее это одна из платформ, под которую собирается код.

И кто, собственно, помешает вам реализовать поддержку соответствующий абстракций для них? Тот же Emscripten эмулирует всё на свете поверх одного массива — совершенно непонятно что может помешать реализовать Boost.Context для него.

… Используя сакральное знание о деталях реализации Emscripten. И если вдруг подход поменяется (например, в сторону JS objects как у альтернатив), то внезапно все перестанет работать. Собственно в этом и есть главный изъян подхода, когда библиотека берет на себя platform-specific вещи.

Возражения против принятия Coroutines с await в C++17

Не могу не согласиться, что реализации на основе Boost.Context мягко говоря имеют не меньшее количество проблем.
1) Про платформенно-зависимость было упомянуто. Список поддерживаемых архитектур довольно скуден. Сохранение стэка с регистрами никогда не заработает для экзотических платформ, типа Emscripten (компиляция C++ в asm.js).
2) Boost.Context не решает проблему "параллельности" стандартной библиотеки.

Совместное редактирование. Часть 2

Вот есть подборка по редактирования офисных документов. Но скажу честно, что опыта установки ничего из этого нет. Если формат конкретно офисных документов не принципиален, то стоит посмотреть в сторону Apache Wave (бывший Google Wave).

Совместное редактирование. Часть 2

Пожалуйста, приятно, что кому-то она была интересной!

Совместное редактирование. Часть 1

Вышла вторая часть статьи. Там есть ответы на многие вопросы из комментариев :)

Совместное редактирование. Часть 1

OT с tombstones? Необычно…

Самое простое и эффективное решение FalseTie на мой взгляд.

У OT в оффлайне нарастает сложность задачи merge нетривиальным образом. Вы тестировали такие сценарии?

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

Совместное редактирование. Часть 1

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

По поводу «аптеки» и «оптики» — для классического OT будет, естественно гибрид, хотя отслеживать такие конфликты возможность есть. Но и в зависимости от правил мержа это тоже может быть автоматически смержено, либо помечено как конфликт.

Совместное редактирование. Часть 1

в чём проблема смёржить иерархические документы?

Проблема в том, что алгоритм автоматического мержа вынужден выбирать между надежностью и удобством для пользователя. То есть либо мы выбираем надежный алгоритм, который будет чаще просить пользователя смержить вручную. Либо более интеллектуальный, но который может дать неверный результат. По сравнению с простым текстом сложность мержа полноценного документа больше: представьте, что один пользователь добавил несколько строк в таблицу, а другой несколько столбцов. И при этом они отредактировали содержимое нескольких ячеек.
Кроме того, интерфейс ручного мержа офисных документов не может быть проще чем существующие утилиты для 3-way мержа. Вероятнее всего он будет значительно сложнее, а это значит, что пользователей нужно научить с ним работать.

1. Для каждого документа хранится вся история трансформаций (много весят, выборки тормозят и тп)

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

Малейший баг в алгоритме (а алгоритмы тут довольно нетривиальные) легко может запороть документ

Да, алгоритм должен быть качественно оттестирован. Кроме того, счет наличия истории всегда можно откатиться к последнему валидному состоянию.

Для получения актуальной версии нужно плясать с бубном

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

Хранить нужно лишь последнюю актуальную версию и применять к ней патчи от клиентов.

В этом как раз основная разница между ОТ и мержем. OT работает с операциями и имеет информацию о том, как менялся документ. Мерж имеет дело только с конечными состояниями и уже постфактум находит одинаковые и отличающиеся части, что дает намного меньше возможности «свести» различные изменения пользователей.

Информация

В рейтинге
Не участвует
Откуда
Харьков, Харьковская обл., Украина
Работает в
Дата рождения
Зарегистрирован
Активность