Статья - информационный шум, цель которого зацепить как можно больше волнующих тем и сказать как можно больше провокационных неаргументированных фактов, + приправить это ИИ картинками чтобы скучно не было.
Видимо целью было прорекламировать себя за счет популярной нынче темы. Уже все жевано пережевано на эту тему даже на хабре, а эти статьи все еще набирают кучу плюсов
Может скажем ему? На мой взгляд, забивать голову 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 быстро менять профили настроек
а с чего вы взяли что можете прийти к человеку и сказать - эй, вот те работенка, надо сделать, мне так удобно. Для него ваш cmake такой же анус как для вас его configure && make)
Для одного проекта, который саппортит один разраб, который чтобы скомпилировать, надо так напрячься, что потом уже не захочется.
кстати, как вы там это собирали? Я за 5 минут управился - запустил make -j. Всего одна проблема вылезла - -Wincompatible-pointer-types. Спасибо за ссылочку, интересно изучить.
по-моему коммиты в open-source это куда более хорошее подтверждение опыта чем строчка в трудовой. Если б они еще вели issue-tracker в открытую - цены бы не было
из вашего комментария у меня сложилось впечатление что вы пытаетесь понимать как и зачем написан код вместо того чтобы понимать что он делает. Грубо говоря - когда я разбираюсь в коде я пытаюсь понять что он делает. По мере изучения я могу углубиться в какую-то часть кода чтобы понять КАК она это делает, если я думаю что баг где-то тут. Но по большей части я не выясняю как работает сортировка и почему автор написал бабл сорт, а не квик сорт или например почему он использует тут std::list, а не std::vector.
Моё впечатление верное? Если да, то я не совсем понимаю зачем вы углубляетесь в это так сильно. Чаще всего такого пристального изучения у меня требует очень небольшая часть кода. И это необязательно чтобы увидеть картинку/взаимосвязи
Статья - информационный шум, цель которого зацепить как можно больше волнующих тем и сказать как можно больше провокационных неаргументированных фактов, + приправить это ИИ картинками чтобы скучно не было.
Видимо целью было прорекламировать себя за счет популярной нынче темы. Уже все жевано пережевано на эту тему даже на хабре, а эти статьи все еще набирают кучу плюсов
Может скажем ему? На мой взгляд, забивать голову 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 быстро менять профили настроек
а с чего вы взяли что можете прийти к человеку и сказать - эй, вот те работенка, надо сделать, мне так удобно.
Для него ваш cmake такой же анус как для вас его configure && make)
кстати, как вы там это собирали? Я за 5 минут управился - запустил
make -j. Всего одна проблема вылезла --Wincompatible-pointer-types. Спасибо за ссылочку, интересно изучить.по-моему коммиты в open-source это куда более хорошее подтверждение опыта чем строчка в трудовой. Если б они еще вели issue-tracker в открытую - цены бы не было
как раз упрощением он и занимается когда не добавляет проперти в язык
и правда - просто жесть
https://godbolt.org/z/n4x6d976W
Не особо в теме, но разве go/cpp не может?
Предположу что любой компилируемый язык использующий llvm как бекенд имеет тулчейн для компиляции в wasm
🫡
из вашего комментария у меня сложилось впечатление что вы пытаетесь понимать как и зачем написан код вместо того чтобы понимать что он делает.
Грубо говоря - когда я разбираюсь в коде я пытаюсь понять что он делает. По мере изучения я могу углубиться в какую-то часть кода чтобы понять КАК она это делает, если я думаю что баг где-то тут. Но по большей части я не выясняю как работает сортировка и почему автор написал бабл сорт, а не квик сорт или например почему он использует тут std::list, а не std::vector.
Моё впечатление верное?
Если да, то я не совсем понимаю зачем вы углубляетесь в это так сильно. Чаще всего такого пристального изучения у меня требует очень небольшая часть кода. И это необязательно чтобы увидеть картинку/взаимосвязи