Третий абзац статьи. Там говорится про QML. Так же как и в оглавлении книги.
А вообще, виджеты достаточно стабильная технология для десктопов и она поддерживается до сих пор, просто новых фичей не добавляют. Но у виджетов есть ряд фундаментальных проблем:
Виджеты жрут CPU на основном потоке и провоцируют на микс бизнес и UI логики. Из-за этого сложно чинить производительность в легаси системах.
Очень слабая и ресурсоёмка поддержка анимаций интерфейса.
Неудобная кастомизация (часто через тормознутый qss, который сами ребята из Qt не рвутся оптимизировать).
Непонятно из статьи, насколько глубоко в книге раскрыты современные практики по разработке интерфейсов на QML / QtQuick? Как я понял, основной упор делается на виджеты, а для современных проектов, где нужна нормальная поддержка dpi scaling или для мобильных систем / HMI это уже не особо подходит.
Я больше склоняюсь к тому, что это эффективные манагеры экономят за счет монополии Яндекса. Типа пофиг, что некоторые клиенты страдают, пока монополия - бизнесу это не повредит. И это очень грустно. С одной стороны я сейчас для своих проектов осваиваю userver, с ребятами из Яндекса общаться одно удовольствие, а с другой, конечные продукты обрастают толстым слоем всякого *****.
P.S. в моем случае была ситуация, что у меня отвалился семейный аккаунт в РБ: белорусская карта привязана, сам аккаунт на белорусской симке, впн с точкой выхода в РБ, но я так и не смог его восстановить и мой папа б не мог пользоваться моей картой. Причем отвязать карту от своего аккаунта и привязать карту к его аккаунту я не смог. «Поддержка» пол года кормила завтраками, но по существу так и не помогла.
Ну я пробовал только в РБ и Узбекистане. Последний - вообще тяжелый случай. А вот в Беларуси раньше было всё ок, попросишь проэскалировать и соединяли с следующей линией поддержки и действительно решали вопросы. Примерно года до 2022.
С вами общались примерно так же, как разговаривает типовая техподдержка Яндекса в РБ. То есть никак. Теперь мы знаем, что так общаться могут не только боты, но и люди (возможно, ботов на них обучали). С какого-то времени получить адекватный ответ на реальные проблемы с чёткими шагами воспроизведения просто невозможно. Всё сводится к методичке: почистите кэш на iOS, переустановите ОС, откройте карточку в другом банке, до свидания, мы больше ничем вам не можем помочь.
Правильная идиома: после std::moveотноситесь к объекту так, как будто он только что был создан конструктором по умолчанию.
Ни разу она не правильная. Объект после перемещения нельзя так трактовать. Таких гарантий нет, особенно для пользовательских типов. Есть лишь правило, что объект должен быть в корректном состоянии, чтобы нормально мог отработать деструктор - этого достаточно понимать.
А сырые указатели и ручной new / delete вообще не нужно использовать в подводящем большинстве случаев. Как правило, за исключением реализации собственных контейнеров или умных указателей.
Вы знаете, есть такая полезная штука - вычитка. С картинками глаз не так замыливается как с текстом и такие вещи должны легко отлавливаться. Конечно же, если вы уважаете комьюнити, а не просто раскручиваете аккаунт.
К примеру, на тех же код ревью, я всегда вычитываю свой код так, как будто я - ревьювер. И только потом отдаю это на проверку команде и далее по процессу.
У вас на первой картинке ошибка, порядок действий неверный: 1-2-3-4-7-6-5, а должно быть последовательно. Оплата налогов и успешный ввоз не может чисто логически произойти до пересечения товаром границы :)
Пользователь приходит сюда заказать еду или выбрать ресторан.
Как пользователь, когда я хочу сходить в ресторан, я открываю интересующий меня район в картах и уже там перебираю рестораны.
Но, к сожалению, это уже не новая тенденция Яндекса - делать «супер приложения» для втюхивания большего количества рекламы. Когда основному функционалу приложения отводится менее 50% а то и 80% места на экране.
Вот и приходится продираться сквозь все эти высоко оптимизированные слои спама, чтобы добраться до основной функциональности - доставки еды.
P.S. с технической точки зрения было интересно почитать, спасибо.
Таким не занимался, но все равно мне кажется, что раз уж перехватываем создание потока, то можно и проинициализировать всё нужное самим.
Я бы делал так, берём тот же detours, заменяем CreateThread на свой, где вначале делается инициализация ну и ждем по какому нибудь мьютексу (который в винапи CreateEvent) сигнала к запуску оригинальной функции потока.
Впрочем ок, пусть будет такой флаг. Для таких тонких вещей платформозависимый код это, как правило, необходимость.
А какой практический пример у этого флага? Если процесс ещё понятно (вдруг, что-то пропатчить налету надо, до первой команды), то с потоком - не понятно.
Я сам начинал с винапи, включая многопоточку (тогда MSDN еще на компакт дисках поставлялся, интернет был дорогой и медленный). Но когда минимально освоил ООП - забыл как страшный сон. Хотя, как ни странно, где-то раз в 4 года приходится вспоминать :)
Немного оффтопик. Скажите, а не планируется ли возвращение подписок для студентов и индивидуальных разработчиков? И, если не секрет, почему их свернули? Было много разных злоупотреблений и, как следствие, упущенной выгоды?
У меня Microsoft arc mouse, а не та что в статье. Не знаю насчет саморазряда, использую редко, уже лет 5 не менял батарейки, там 2 штуки ааа. Это не геймерская мышь, хватает очень надолго.
У меня уже много лет Microsoft Arc mouse в качестве резервного варианта при поездках. Крайне удобно, когда устаёшь возиться с тачпадом. В сложенном виде плоская, влазит в любой кармашек. При этом практически полноценная функциональность: механические кнопки, горизонтальный и вертикальный сенсорный скролл с тактильным откликом (достаточно удобный). Из минусов: нужно привыкнуть, так как хват получается другой.
Третий абзац статьи. Там говорится про QML. Так же как и в оглавлении книги.
А вообще, виджеты достаточно стабильная технология для десктопов и она поддерживается до сих пор, просто новых фичей не добавляют. Но у виджетов есть ряд фундаментальных проблем:
Виджеты жрут CPU на основном потоке и провоцируют на микс бизнес и UI логики. Из-за этого сложно чинить производительность в легаси системах.
Очень слабая и ресурсоёмка поддержка анимаций интерфейса.
Неудобная кастомизация (часто через тормознутый qss, который сами ребята из Qt не рвутся оптимизировать).
Непонятно из статьи, насколько глубоко в книге раскрыты современные практики по разработке интерфейсов на QML / QtQuick? Как я понял, основной упор делается на виджеты, а для современных проектов, где нужна нормальная поддержка dpi scaling или для мобильных систем / HMI это уже не особо подходит.
Я больше склоняюсь к тому, что это эффективные манагеры экономят за счет монополии Яндекса. Типа пофиг, что некоторые клиенты страдают, пока монополия - бизнесу это не повредит. И это очень грустно. С одной стороны я сейчас для своих проектов осваиваю userver, с ребятами из Яндекса общаться одно удовольствие, а с другой, конечные продукты обрастают толстым слоем всякого *****.
P.S. в моем случае была ситуация, что у меня отвалился семейный аккаунт в РБ: белорусская карта привязана, сам аккаунт на белорусской симке, впн с точкой выхода в РБ, но я так и не смог его восстановить и мой папа б не мог пользоваться моей картой. Причем отвязать карту от своего аккаунта и привязать карту к его аккаунту я не смог. «Поддержка» пол года кормила завтраками, но по существу так и не помогла.
Ну я пробовал только в РБ и Узбекистане. Последний - вообще тяжелый случай. А вот в Беларуси раньше было всё ок, попросишь проэскалировать и соединяли с следующей линией поддержки и действительно решали вопросы. Примерно года до 2022.
С вами общались примерно так же, как разговаривает типовая техподдержка Яндекса в РБ. То есть никак. Теперь мы знаем, что так общаться могут не только боты, но и люди (возможно, ботов на них обучали). С какого-то времени получить адекватный ответ на реальные проблемы с чёткими шагами воспроизведения просто невозможно. Всё сводится к методичке: почистите кэш на iOS, переустановите ОС, откройте карточку в другом банке, до свидания, мы больше ничем вам не можем помочь.
Вы забыли сказать, что когда её релизили, то обещали lifetime поддержку с инкрементальными апдейтами. И что новые версии больше будут не нужны.
Но нет, надо было сделать «пуск» по центру с менюхами на react native и всунуть кортану/копайлот везде куда надо и не надо.
Ни разу она не правильная. Объект после перемещения нельзя так трактовать. Таких гарантий нет, особенно для пользовательских типов. Есть лишь правило, что объект должен быть в корректном состоянии, чтобы нормально мог отработать деструктор - этого достаточно понимать.
А сырые указатели и ручной new / delete вообще не нужно использовать в подводящем большинстве случаев. Как правило, за исключением реализации собственных контейнеров или умных указателей.
Автор, что же вы удалили свою вторую статью? Или по ней стала более очевидна «глубина» ваших познаний в многопоточном программировании?
Вы знаете, есть такая полезная штука - вычитка. С картинками глаз не так замыливается как с текстом и такие вещи должны легко отлавливаться. Конечно же, если вы уважаете комьюнити, а не просто раскручиваете аккаунт.
К примеру, на тех же код ревью, я всегда вычитываю свой код так, как будто я - ревьювер. И только потом отдаю это на проверку команде и далее по процессу.
У вас на первой картинке ошибка, порядок действий неверный: 1-2-3-4-7-6-5, а должно быть последовательно. Оплата налогов и успешный ввоз не может чисто логически произойти до пересечения товаром границы :)
Увы, там нет упоминания вариантов для closed source проектов. Как я понял, для разработчиков-одиночек по прежнему нет вариантов за вменяемые деньги?
За возвращение студенческой подписки - спасибо.
Как пользователь, когда я хочу сходить в ресторан, я открываю интересующий меня район в картах и уже там перебираю рестораны.
Но, к сожалению, это уже не новая тенденция Яндекса - делать «супер приложения» для втюхивания большего количества рекламы. Когда основному функционалу приложения отводится менее 50% а то и 80% места на экране.
Вот и приходится продираться сквозь все эти высоко оптимизированные слои спама, чтобы добраться до основной функциональности - доставки еды.
P.S. с технической точки зрения было интересно почитать, спасибо.
Таким не занимался, но все равно мне кажется, что раз уж перехватываем создание потока, то можно и проинициализировать всё нужное самим.
Я бы делал так, берём тот же detours, заменяем CreateThread на свой, где вначале делается инициализация ну и ждем по какому нибудь мьютексу (который в винапи CreateEvent) сигнала к запуску оригинальной функции потока.
Впрочем ок, пусть будет такой флаг. Для таких тонких вещей платформозависимый код это, как правило, необходимость.
А какой практический пример у этого флага? Если процесс ещё понятно (вдруг, что-то пропатчить налету надо, до первой команды), то с потоком - не понятно.
Да, действительно. Только не особо переносимо.
Я сам начинал с винапи, включая многопоточку (тогда MSDN еще на компакт дисках поставлялся, интернет был дорогой и медленный). Но когда минимально освоил ООП - забыл как страшный сон. Хотя, как ни странно, где-то раз в 4 года приходится вспоминать :)
Какое преимущество у WinApi перед стандартными функциями Си++?
Немного оффтопик. Скажите, а не планируется ли возвращение подписок для студентов и индивидуальных разработчиков? И, если не секрет, почему их свернули? Было много разных злоупотреблений и, как следствие, упущенной выгоды?
У меня Microsoft arc mouse, а не та что в статье. Не знаю насчет саморазряда, использую редко, уже лет 5 не менял батарейки, там 2 штуки ааа. Это не геймерская мышь, хватает очень надолго.
У меня уже много лет Microsoft Arc mouse в качестве резервного варианта при поездках. Крайне удобно, когда устаёшь возиться с тачпадом. В сложенном виде плоская, влазит в любой кармашек. При этом практически полноценная функциональность: механические кнопки, горизонтальный и вертикальный сенсорный скролл с тактильным откликом (достаточно удобный). Из минусов: нужно привыкнуть, так как хват получается другой.
А можете сделать сравнение с Restinio? - https://habr.com/ru/articles/773608/