А можете привести пример когда условно булеан 10 раз меняется туда и обратно. Вы в статье писали что благодаря Virtual DOM в DOM пойдет только измененное состояние. Т.е. в случае булеана может ничего не пойти, если он вернулся в конце в изначальное состояние. Случай вроде валидный и показывает зачем нужен Virtual DOM. Но где на практике такое бывает? - что одни и те же данные меняются очень часто? Это явно не кнопка
а можете в двух словах написать зачем нужен Virtual DOM? Или дать ссылку на годный ресурс?
Я из статьи понял: при любом ивенте ходить сразу в DOM дорого, поэтому создадим себе "копию" (Virtual) этого DOM и будем ее иногда пушить в реальный. В принципе звучит логично, но автор то говорит "браузеры умные и не будут перерисовывать при каждом изменении DOM", то говорит что "писать в DOM по поводу и без всё-таки дорого".
В итоге люди придумали скопировать состояние и пытаться его синхронизировать, что по моему опыту только добавляет багов.
Честно говоря, любопытно как вам (или кому-то другому?) удалось убедить мэнтейнеров постгрес добавить C++ в кодовую базу... Глядя на проекты вроде линукса и постгреса создается впечатление - ну ребята пишут на Си, значит понимают зачем и им так удобнее. А тут из статьи впечатление что ребята не очень и понимают...
в Rust невозможны вопросы "что выведет эта программа", там все инструкции явные
Думаю вы сильно ошибаетесь считая что в Rust все определенно ясно. Да и Rust вроде бы не делает на этом упор как Zig.
Пара примеров неочевидных вещей:
Загадка. Одна из этих строк не скомпилируется. Какая?
let a1: _ = [b"a", b"a" as &[u8]];
let b1: _ = [b"a" as &[u8], b"a"];
let a2: [_; 2] = [b"a", b"a" as &[u8]];
let b2: [_; 2] = [b"a" as &[u8], b"a"];
let a3: [&[u8]; 2] = [b"a", b"a" as &[u8]];
let b3: [&[u8]; 2] = [b"a" as &[u8], b"a"];
Имеете доступ к структуре за иммутабельной ссылкой, но хотите мутировать ее поле? Отрицаете любые авторитеты и хотите назло маме отморозить уши? Вас спасет баг rustc, заставляющий его автодополнять unsafe перед фигурными скобками:
Такие скользские и неочевидные места нормальны и появляются когда язык или технология развивается. С этим ничего не поделаешь т.к. невозможно знать в самом начале как и что будет добавлено в язык в будущем. Впрочем у Rust есть твердный фундамент из базовых концепций, который сильно помогает с этим
Слишком мало деталей. Быть может как ваш путь пойдет, но чтобы это было полезно кому-то нужно конкретные ошибки и решения описывать. Да и обратно в llvm неплохо было бы сделать PR
Статья - информационный шум, цель которого зацепить как можно больше волнующих тем и сказать как можно больше провокационных неаргументированных фактов, + приправить это ИИ картинками чтобы скучно не было.
Видимо целью было прорекламировать себя за счет популярной нынче темы. Уже все жевано пережевано на эту тему даже на хабре, а эти статьи все еще набирают кучу плюсов
Может скажем ему? На мой взгляд, забивать голову gui нет смысла. Достаточно понимания как это работает. В cli гораздо проще, удобней и главное полезней, видеть, понимать и контролировать сделанное тобой, командой и вообще смотреть на историю и изменения.
Мне кажется у вас подход неэффективый. Как по мне, если вам нужно подумать и принять решение о переключении, то это уже медленно + лень думать каждый раз. Я использую разные клавиши для переключение между раскладками - на английский LAlt, русский RAlt. Заметил как вошло в привычку нажимать соответствующую перед началом ввода. Думать не нужно + эти клавиши очень близко к толстым пальцам обеих рук
и что вам даст проверка safe кода? Вы ведь будете проверять его с учётом инвариантов? Если нет, то что вы вообще хотите проверить. Если ли да, тогда весь safe код окажется внезапно корректным. Потому что диалог как раз про те ситуации когда unsafe нарушает инварианты
Для меня C++ является языком, требующим колоссального внимания в силу неимоверного количества правил, исключений и просто абсолютно нелепых конструкций с точки зрения языкостроения.
приватные функции это точно такой же интерфейс для вашего кода, как ваш интерфейс для пользователя класса/библиотеки.
Почему вы считаете что интерфейс пользователя нужно тестировать, а интерфейс которым пользуетесь вы - нет?
В тесты вкладывают довольно широкий спектр смыслов, но, как по мне, если у вас есть какая-то логика, то тесты вполне уместны для проверки ее корректности - не важно является эта логика интерфейсом или деталью реализации
Вот и живем так что весь код пропитан QString::toStdWStribg / fromStdWString
Так что это и моя боль :(
Изначально я отвечал на UPD, где вы предлагали способы решения этого зоопарка. Поэтому я не имел ввиду что мои способом можно решить проблема с Qt. Уж извините если ввел в заблуждение :)
Но.. мне пришла в голову безумная идея - использовать type erasure чтобы можно было положить разные типы символов в один "string_view". Как пример такого контейнера это std::ranges::any_view
А как std::string_view будет у вас работать с QString, если у последнего внутри QChar и он внутри UTF-16 содержит? sizeof(QChar) == 2
Работает с разными типами строк - std::string, CString, MyCoolString. С другим типом char_type конечно не будет. Это проблемка, но я для себя вижу как решение просто использовать везде utf8 строки с char
да то же не сильно хорошее решение, ну а какой вариант?
вариант это вообще не позволять владеющим строкам просачиваться в интерфейс. Если вам внутри не нужно хранить полученную строку, то это просто эффективнее. Если нужно хранить, то принимая владеющий тип в функцию вы раскрываете деталь реализации. std::string_view хороший вариант для стабильного апи. Он может работать почти с любой строкой (разве что есть строки которые не аллоцированы как один кусок памяти).
Ещё более спартанский вариант это char* + size_t. Это для сишного апи.
Но на деле это мало кто будет о таких мелочах задумываться. Влепят аппрув и поехали.. Вот и живем так что весь код пропитан QString::toStdWStribg / fromStdWString
Любая кастомизация хоткеев и окон - превращает тебя в овоща, при необходимости сесть за новый ПК или при необходимости 5 минут посидеть за клавиатурой коллеги
Тут вы, мне кажется, преувеличили. Конечно без своих конфигов пользоваться чужим ПК намного менее удобно, но далеко от овоща.. 10 минут в день я готов и мышью покликать, зато остальное 99% времени комфортно себя чувствовать. Аналогично например с fd, rg вместо find, grep. Безусловно последними нужно уметь пользоваться, но, как по мне, бестолку предпочитать их если 99% времени можно заменить их на что-то более удобное.
У меня, кстати, есть немного другой кейс: когда не тебе нужно потыкать ПК коллеги, а наоборот - ему твой. Вот тут кастомизация превращает этот процесс в игру в глухой телефон... Надо бы разобраться как в visual studio быстро менять профили настроек
в один день?
вы из 2021 это пишете?
А можете привести пример когда условно булеан 10 раз меняется туда и обратно.
Вы в статье писали что благодаря Virtual DOM в DOM пойдет только измененное состояние. Т.е. в случае булеана может ничего не пойти, если он вернулся в конце в изначальное состояние. Случай вроде валидный и показывает зачем нужен Virtual DOM.
Но где на практике такое бывает? - что одни и те же данные меняются очень часто? Это явно не кнопка
а можете в двух словах написать зачем нужен Virtual DOM? Или дать ссылку на годный ресурс?
Я из статьи понял: при любом ивенте ходить сразу в DOM дорого, поэтому создадим себе "копию" (Virtual) этого DOM и будем ее иногда пушить в реальный.
В принципе звучит логично, но автор то говорит "браузеры умные и не будут перерисовывать при каждом изменении DOM", то говорит что "писать в DOM по поводу и без всё-таки дорого".
В итоге люди придумали скопировать состояние и пытаться его синхронизировать, что по моему опыту только добавляет багов.
хм, видимо упустил этот момент.
Но название статьи как будто вводит в заблуждение)
Честно говоря, любопытно как вам (или кому-то другому?) удалось убедить мэнтейнеров постгрес добавить C++ в кодовую базу...
Глядя на проекты вроде линукса и постгреса создается впечатление - ну ребята пишут на Си, значит понимают зачем и им так удобнее. А тут из статьи впечатление что ребята не очень и понимают...
Думаю вы сильно ошибаетесь считая что в Rust все определенно ясно. Да и Rust вроде бы не делает на этом упор как Zig.
Пара примеров неочевидных вещей:
Такие скользские и неочевидные места нормальны и появляются когда язык или технология развивается. С этим ничего не поделаешь т.к. невозможно знать в самом начале как и что будет добавлено в язык в будущем. Впрочем у Rust есть твердный фундамент из базовых концепций, который сильно помогает с этим
Примеры взяты из https://t.me/alisa_rummages
Там еще парочка есть
Слишком мало деталей.
Быть может как ваш путь пойдет, но чтобы это было полезно кому-то нужно конкретные ошибки и решения описывать. Да и обратно в llvm неплохо было бы сделать PR
Статья - информационный шум, цель которого зацепить как можно больше волнующих тем и сказать как можно больше провокационных неаргументированных фактов, + приправить это ИИ картинками чтобы скучно не было.
Видимо целью было прорекламировать себя за счет популярной нынче темы. Уже все жевано пережевано на эту тему даже на хабре, а эти статьи все еще набирают кучу плюсов
Может скажем ему? На мой взгляд, забивать голову gui нет смысла. Достаточно понимания как это работает. В cli гораздо проще, удобней и главное полезней, видеть, понимать и контролировать сделанное тобой, командой и вообще смотреть на историю и изменения.
хм, мне в голову первое пришло cherry-pick,
а есть что почитать конкретно про этот кейс или про onto rebase?
Мне кажется у вас подход неэффективый.
Как по мне, если вам нужно подумать и принять решение о переключении, то это уже медленно + лень думать каждый раз.
Я использую разные клавиши для переключение между раскладками - на английский LAlt, русский RAlt. Заметил как вошло в привычку нажимать соответствующую перед началом ввода. Думать не нужно + эти клавиши очень близко к толстым пальцам обеих рук
и что вам даст проверка safe кода? Вы ведь будете проверять его с учётом инвариантов? Если нет, то что вы вообще хотите проверить. Если ли да, тогда весь safe код окажется внезапно корректным.
Потому что диалог как раз про те ситуации когда unsafe нарушает инварианты
приведите пару примеров нелепых конструкций
приватные функции это точно такой же интерфейс для вашего кода, как ваш интерфейс для пользователя класса/библиотеки.
Почему вы считаете что интерфейс пользователя нужно тестировать, а интерфейс которым пользуетесь вы - нет?
В тесты вкладывают довольно широкий спектр смыслов, но, как по мне, если у вас есть какая-то логика, то тесты вполне уместны для проверки ее корректности - не важно является эта логика интерфейсом или деталью реализации
да ни как) как я и написал в первом ответе:
Так что это и моя боль :(
Изначально я отвечал на UPD, где вы предлагали способы решения этого зоопарка. Поэтому я не имел ввиду что мои способом можно решить проблема с Qt. Уж извините если ввел в заблуждение :)
Но.. мне пришла в голову безумная идея - использовать type erasure чтобы можно было положить разные типы символов в один "string_view". Как пример такого контейнера это std::ranges::any_view
добавлю что эти коллбэки ещё и значительно усложняют дебаггинг
Работает с разными типами строк - std::string, CString, MyCoolString.
С другим типом char_type конечно не будет.
Это проблемка, но я для себя вижу как решение просто использовать везде utf8 строки с
charвариант это вообще не позволять владеющим строкам просачиваться в интерфейс. Если вам внутри не нужно хранить полученную строку, то это просто эффективнее. Если нужно хранить, то принимая владеющий тип в функцию вы раскрываете деталь реализации.
std::string_view хороший вариант для стабильного апи. Он может работать почти с любой строкой (разве что есть строки которые не аллоцированы как один кусок памяти).
Ещё более спартанский вариант это char* + size_t. Это для сишного апи.
Но на деле это мало кто будет о таких мелочах задумываться. Влепят аппрув и поехали.. Вот и живем так что весь код пропитан QString::toStdWStribg / fromStdWString
std::string скорее аскетична..
как и вся std
Тут вы, мне кажется, преувеличили. Конечно без своих конфигов пользоваться чужим ПК намного менее удобно, но далеко от овоща.. 10 минут в день я готов и мышью покликать, зато остальное 99% времени комфортно себя чувствовать. Аналогично например с fd, rg вместо find, grep. Безусловно последними нужно уметь пользоваться, но, как по мне, бестолку предпочитать их если 99% времени можно заменить их на что-то более удобное.
У меня, кстати, есть немного другой кейс: когда не тебе нужно потыкать ПК коллеги, а наоборот - ему твой. Вот тут кастомизация превращает этот процесс в игру в глухой телефон... Надо бы разобраться как в visual studio быстро менять профили настроек