Именно поэтому в cpp core guidelines для мер использовать специальные типы данных. Тогда не будет никакой путаницы с корректностью рассчётов даже при повсеместном auto
Если при включении оптимизации выше чем O1 в релизной сборке у вас начинаются проблемы, то это прямой показатель того, что что-то где-то криво запрограммировано.
Предложите, как можно сокращённо назвать msvs for Mac? Классическую студию мы с коллегами называем «вижла», что понятно. С Visual Studio Code тоже быстро разобрались, она стала называться «вэ эс код». Но маркетологи Майкрософта не успокаиваются :). Подскажите, как можно лаконично называть вижлу для мака?
Конечно, мы также продолжаем поддерживать и улучшать кроссплатформенную разработку на C++
Вот можно про этот момент чуть подробнее? А то вообще нет никакой информации о перспективах С++ в рамках MSVS 2019.
И ещё вопрос. Может я не совсем правильно понял, но MSVS 2019 для Windows и MSVS 2019 для MacOS — это две совершенно разные IDE, которые теперь будут одинаково называться?
Нормально устранить получится только для жёсткой конструкции. В крайнем случае — конструкции с предсказуемой механикой. Человеческое тело к таким не относится, разве что удастся натренировать рефлекс «вытянуться по стойке смирно» в случае отказа одного из двигателей, что очень сложно.
Я прошёл схему Pascal -> C -> WinApi (имхо, паскаль лишний в этой цепочке, но он был полезен более слабым ученикам). Плюсы изучал самостоятельно и первые года 2-3 реальной работы писал на си с классами, пока не познакомился с Qt. Не могу сказать, что это было плохо, но и не сказать что было хорошо. Минусы в таком подходе очевидны — мне было очень сложно приучиться к ООП мышлению и было сложно понять назначение паттернов проектирования. Много времени я был где-то между сильным джуном и слабым мидлом.
Считаю, что в этой цепочке просто не хватило следующего звена — а именно хорошего жёсткого курса по ООП с изобилием практики. Да, в универе у нас читали ООП (на примере консольных приложений в Делфи, никаких формочек) и читали хорошо. Но на лабах это не закреплялось. К тому же на тот момент я уже работал и мне было не до универа.
У меня как-то раз был спор на собеседовании, где я быстро понял, что мне сбивают цену. Я проявил упрямство, попросил дать ноутбук чтобы продемонстрировать что я прав (если не ошибаюсь, про инлайнинг и RVO спорили). На что директор начал психовать, мол что вы тут за цирк устраиваете и т.п. Пришлось в лоб сказать, что если враньё начинается уже на собеседовании, то работать я сюда не пойду. После чего ушёл. Через пару месяцев, когда я уже успешно работал в другой фирме мне позвонили эти ребята и сделали оффер. От которого я конечно же отказался. Оффер к тому же был на 50% серый.
Уважаемый Crossover. А вы можете расписать вашу иерархию квалификаций разработчиков? Начиная от джуна, заканчивая супер пупер архитектором (или выше).
Часто натыкаюсь на ваши вакансии и улыбаюсь от указанных там позиций. Складывается впечатление, что у вас на всех позициях работают только тех директора и тому подобные.
Я тоже бомбану по поводу скайпа. Вот всякую дичь типа смайликов вводите — это хорошо. Но зачем искусственно обрезать старый функционал?
Недавно устроился на новую работу, практически первым делом решили разделить флудилку на два канала: 1 для официальных объявлений (у всех уведомлялки включены, все читают), 2 канал для флуда. Так вот, раньше в пару команд можно было включить модерацию и запретить писать в чат всем, кроме тех, кто делает объявления. А сейчас это просто убрали. Увы, инерция бизнеса не позволяет пока перейти на что-то другое, потому что со скайпом чем дальше — тем хуже. Единственное, что до сих пор радует — это качество звонков.
Ну да, тут вопрос в масштабах проекта. Если человек 20-30 его делают, то резко возрастает вероятность появления кучи велосипедов с перекрывающийся функциональностью. Я с таким сталкивался. Поэтому считаю, что если вы рассчитываете на реюзабельность виджета, то нужно делать его максимально продуманным и гибким. И крайне желательно, чтобы он реализовывал стандартные механизмы Qt по кастомизации, а именно поддержку стилей.
По поводу картинок — погуглите по запросу “fatcow icons”. Практически полностью покрывает потребности многих проектов.
Спасибо, конечно, за статью, но кроме обычного рисования на Qt я тут ничего не увидел. Стоит хотя-бы вынести большинство констант в properties, чтобы можно было настраивать поведение через те же стили. А ещё лучше сделать все тоже самое средствами QtQuick, если нужна интерактивность. Там даже параллакс можно достаточно дёшево прикрутить.
Для эффективного рисования таких вещей всё-таки намного проще использовать картинки + qss + QToolButton (это на случай, если всякие hover эффекты хочется из коробки). В крайнем случае, если нужно эффективное масштабирование, можно взять svg, оверхеда практически не будет. Еще режут глаза статические переменные внутри методов.
Я добровольно-принудительно задаю правила по всем именованиям в решарпере для всего проекта. Да и вообще считаю хорошей практикой использовать инструменты для проверки codestyle. В моём случае решарпер бы сразу подсветил опасное место.
Древовидные достаточно сложно унифицировать. Поэтому про них и мало написано. Тем более, что некоторые варианты использования сложно визуализировать, например, когда есть дети у ненулевого столбца и т.п.
Главное — это понять что Qt-шная модель, это не модель данных в общепринятом значении, а, скорее часть логики представления. Лучше даже сказать — адаптер.
Большое спасибо за акцию. Решил позволить себе для личного пользования весь пакет (хотя реально нужен только clion + rscpp). Наконец сполз с модели trial-EAP-trial :)
Предположу, что куча COM legacy.
Именно поэтому в cpp core guidelines для мер использовать специальные типы данных. Тогда не будет никакой путаницы с корректностью рассчётов даже при повсеместном auto
Если при включении оптимизации выше чем O1 в релизной сборке у вас начинаются проблемы, то это прямой показатель того, что что-то где-то криво запрограммировано.
Предложите, как можно сокращённо назвать msvs for Mac? Классическую студию мы с коллегами называем «вижла», что понятно. С Visual Studio Code тоже быстро разобрались, она стала называться «вэ эс код». Но маркетологи Майкрософта не успокаиваются :). Подскажите, как можно лаконично называть вижлу для мака?
Вот можно про этот момент чуть подробнее? А то вообще нет никакой информации о перспективах С++ в рамках MSVS 2019.
И ещё вопрос. Может я не совсем правильно понял, но MSVS 2019 для Windows и MSVS 2019 для MacOS — это две совершенно разные IDE, которые теперь будут одинаково называться?
Нормально устранить получится только для жёсткой конструкции. В крайнем случае — конструкции с предсказуемой механикой. Человеческое тело к таким не относится, разве что удастся натренировать рефлекс «вытянуться по стойке смирно» в случае отказа одного из двигателей, что очень сложно.
Я прошёл схему Pascal -> C -> WinApi (имхо, паскаль лишний в этой цепочке, но он был полезен более слабым ученикам). Плюсы изучал самостоятельно и первые года 2-3 реальной работы писал на си с классами, пока не познакомился с Qt. Не могу сказать, что это было плохо, но и не сказать что было хорошо. Минусы в таком подходе очевидны — мне было очень сложно приучиться к ООП мышлению и было сложно понять назначение паттернов проектирования. Много времени я был где-то между сильным джуном и слабым мидлом.
Считаю, что в этой цепочке просто не хватило следующего звена — а именно хорошего жёсткого курса по ООП с изобилием практики. Да, в универе у нас читали ООП (на примере консольных приложений в Делфи, никаких формочек) и читали хорошо. Но на лабах это не закреплялось. К тому же на тот момент я уже работал и мне было не до универа.
Мне кажется, что тема не раскрыта. Я пока не вижу ни одного реального применения этой «фичи»
Благодарю за пояснения.
У меня как-то раз был спор на собеседовании, где я быстро понял, что мне сбивают цену. Я проявил упрямство, попросил дать ноутбук чтобы продемонстрировать что я прав (если не ошибаюсь, про инлайнинг и RVO спорили). На что директор начал психовать, мол что вы тут за цирк устраиваете и т.п. Пришлось в лоб сказать, что если враньё начинается уже на собеседовании, то работать я сюда не пойду. После чего ушёл. Через пару месяцев, когда я уже успешно работал в другой фирме мне позвонили эти ребята и сделали оффер. От которого я конечно же отказался. Оффер к тому же был на 50% серый.
Уважаемый Crossover. А вы можете расписать вашу иерархию квалификаций разработчиков? Начиная от джуна, заканчивая супер пупер архитектором (или выше).
Часто натыкаюсь на ваши вакансии и улыбаюсь от указанных там позиций. Складывается впечатление, что у вас на всех позициях работают только тех директора и тому подобные.
Я тоже бомбану по поводу скайпа. Вот всякую дичь типа смайликов вводите — это хорошо. Но зачем искусственно обрезать старый функционал?
Недавно устроился на новую работу, практически первым делом решили разделить флудилку на два канала: 1 для официальных объявлений (у всех уведомлялки включены, все читают), 2 канал для флуда. Так вот, раньше в пару команд можно было включить модерацию и запретить писать в чат всем, кроме тех, кто делает объявления. А сейчас это просто убрали. Увы, инерция бизнеса не позволяет пока перейти на что-то другое, потому что со скайпом чем дальше — тем хуже. Единственное, что до сих пор радует — это качество звонков.
Ну да, тут вопрос в масштабах проекта. Если человек 20-30 его делают, то резко возрастает вероятность появления кучи велосипедов с перекрывающийся функциональностью. Я с таким сталкивался. Поэтому считаю, что если вы рассчитываете на реюзабельность виджета, то нужно делать его максимально продуманным и гибким. И крайне желательно, чтобы он реализовывал стандартные механизмы Qt по кастомизации, а именно поддержку стилей.
По поводу картинок — погуглите по запросу “fatcow icons”. Практически полностью покрывает потребности многих проектов.
Спасибо, конечно, за статью, но кроме обычного рисования на Qt я тут ничего не увидел. Стоит хотя-бы вынести большинство констант в properties, чтобы можно было настраивать поведение через те же стили. А ещё лучше сделать все тоже самое средствами QtQuick, если нужна интерактивность. Там даже параллакс можно достаточно дёшево прикрутить.
Для эффективного рисования таких вещей всё-таки намного проще использовать картинки + qss + QToolButton (это на случай, если всякие hover эффекты хочется из коробки). В крайнем случае, если нужно эффективное масштабирование, можно взять svg, оверхеда практически не будет. Еще режут глаза статические переменные внутри методов.
Я добровольно-принудительно задаю правила по всем именованиям в решарпере для всего проекта. Да и вообще считаю хорошей практикой использовать инструменты для проверки codestyle. В моём случае решарпер бы сразу подсветил опасное место.
Древовидные достаточно сложно унифицировать. Поэтому про них и мало написано. Тем более, что некоторые варианты использования сложно визуализировать, например, когда есть дети у ненулевого столбца и т.п.
Главное — это понять что Qt-шная модель, это не модель данных в общепринятом значении, а, скорее часть логики представления. Лучше даже сказать — адаптер.
Спасибо, отлично получилось. Вы меня вдохновили, чтобы тоже что-нибудь про Qt написать из своего опыта :)
А можете вначале или в конце каждой главы под спойлером ссылки на остальные главы?
Первый раз слышу термин «отражение». Для термина reflection, как мне кажется, лучше использовать устоявшийся термин — рефлексия.