Кое-какие диагнозы по первой ссылке точно есть в компании с измерениями различных показателей, но меня это, если честно, не очень интересовало — мы эти сигналы использовали чисто как точки которые надо отрисовать для внутреннего проекта не углубляясь в то что они означают для медиков
Я как бы не зря написал что такие индивидуумы были в основном по непрофильным предметам (правда, автокомплит поменял это слово на неправильные), оно того стоит тратить нервы и время речь идет про односеместровый курс какой-нибудь социологии-правоведения, при том что учился я на инженера, а большинство преподов на таких кафедрах все равно так себе ибо ВУЗ-то технический, а часть преподов работали в нем еще со времен кафедры марскизма-ленинизма (не преувеличение, были случаи аппеляции к собранию сочинений Ленина по совершенно сторонним вопросам)?
По профильным дисциплинам все было гораздо лучше и, как я потом понял увидев билеты к госам, даже лучше чем должно было быть по программе ибо в ней в 2008 году все еще отсутствовала цифровая техника как класс (реально, конечно, про нее рассказывали). Не могу сказать что все было вообще супер, но я это понял только постфактум, а студенту сравнивать особо не с чем было. В любом случае то что тогда давали иногда таки пригождается, а я ведь даже не на программиста учился коим сейчас работаю
В такой формулировке любые наши предположения это только предположения, может там как раз в дальнейшей обработке суть была
А зачем вы это все слушали?
А мы и не слушали, тупо прогуливали эту пару, благо препод настолько был уверен что мы идиоты что на зачете все успевали написать работу и за себя, и за отсутствующего товарища. А по поводу пойти в деканат/на кафедру — был у нас такой случай с параллельной группой, они сходили. По итогам препод остался тем же и сильно обиделся, ребята только проблем от этого огребли
ИМХО, зависит от того на что лабораторка, условно (потому как получаются какие-то ну очень мелкие куски для лабы) «ввод нескольких числе через консоль и поиск максимального с какой-то там обработкой» может быть и на работу с потоками ввода-вывода, и на реализацию алгоритма поиска наибольшего числа. Если первое — то почему бы не задействовать библиотечную функцию?
А вообще по институтским воспоминаниям чем больше препод жалуется на то какие все студенты бездари, тем хуже он сам как специалист и препод. Попадались индивидуумы которые на рассказы какие мы идиоты тратили больше времени чем собственно на свой предмет, правда, по неправильным предметам типа экономики на инженерной специальности
Именно про название доллар можно было бы и побольше написать, особенно учитывая тот факт что «испанский доллар» это, в общем-то, жаргонное название, а сама монета имеет номинал в 8 реалов выполненая в весе европейских талеров (талер — это на немецком, а на английском вполне себе доллар, наверное, не без помощи скандинавов у которых он далер)
Спасибо вам и остальным ответившим. То что он не герболайф понятно, в их существование, наверное, верят только джуниоры. Просто то что его когда-то с такой помпой объявили и 5 лет он подвизается где-то в виде отдельного плагина или же системы сборки в компании с совсем сторонним cmake не может не смущать.
А неясных моментов и багов на ровном месте (типа «не тот z поставили» или «забыли что наша библиотека имеет несколько способов создания объектов») в qt что-то в последнее время стало сильно больше, видимо вы правы про нокию (а может я старею и стал занудой, потому как субъективно кажется что это не только с qt такая проблема)
Может не в тему, но все-таки спрошу — если qbs так хорош и создан чтобы заменить qmake, почему же он до сих пор так и не стал основной системой сборки для qt? Ведь с его представления прошло уже больше 5 лет, у него есть какие-то скрытые проблемы?
Был такой финт пару раз, правда не с начальником, а с заказчиками. Особую пикантность добавляло то что в правилах в одном случае были перечислены вещи, не существовашие на начало разработки, а в другом при их выполнении мы получили втык уже от другого представителя заказчика — он считал что делать надо ровно наоборот :)
Мы в таких случаях начали плодить базовые протоколы и классы и уже от них наследоваться. А что-то уходило и в категории.
Хотя бывало что переиспользовали и отдельные части, скажем, когда все в целом то же самое, вид выглядит по другому для какого-то одного частного случая.
Рантайм это Instruments или valgrind подобные? Они же вроде не могут сами перебирать разные варианты что было бы если код пойдет по такой ветке if-а, а кланг может причем делает это между различными методами
Может не совсем в кассу, но я бы еще упомянул следующие (увы, все для obj-c): https://github.com/nst/objc_dep — строит граф зависимостей фаилов, можно оценить насколько все связано друг с другом в визуальной форме, а иногда и обнаружить что у тебя есть фаилы стоящие отдельно и ни с чем ни линкуемые http://uncrustify.sourceforge.net/ — форматер, довольно известный и универсальный (работает с C, C++, C#, ObjectiveC, D, Java, Pawn и VALA) https://pmd.github.io/pmd-5.4.1/usage/cpd-usage.html — поиск дублирующего кода, тоже для кучи всего, но есть и поиск для obj-c. Раньше он был через сторонний плагин, теперь похоже прямо в ванильной версии (каюсь — не пробовал, как-то раньше обходился старой версией, а в последнее время не использовал)
Ну и есть еще такой вопрос (который я уже пару раз задавал, но ответа пока не получил) — а вы проверяли как приведенные вами анализаторы ведут себя с тем же тайфуном? По моим наблюдениям, кланг попросту перестает проверять то что подключено через тайфун т.к. не видит свзяи между классами (оно и понятно — там линкуется-то только протокол, сам класс уже в рантайме оказывается связан).
Я ж уже выше написал, мой пост ответ на «не умеете готовить» и основной его смысл не показать что на qt нельзя писать, а по спорить с тем что QML безгрешен, а все проблемы из-за кривых рук (а такое утверждение я не первый раз вижу, если быть до конца честным ответ во многом был написан к такой же фразе в более раннем топике, но там это был бы оффтоп). Так-то qt и qml мне скорее нравится, но тем не менее если он мне попадется на работе, я сразу предупрежу о большом числе багов и хотя эти баги безусловно решаемы, риск потратить на задачу существенно больше времени чем планировал есть и он выше чем у родных сдк
По поводу же неразрешимой стены — ее практически нигде нет, вопрос в затратах на преодоление.
Кто ж спорит что баги везде есть, на править сам у меня ни знаний (qt я по факту использую только в домашних проектах и то не всегда), ни времени нет, увы, но я страраюсь хотя бы заводить их с максимальной детализацией, в своем ответе вообще приводил только те что завел сам либо же (в первом пункте) баг завели по результатам моего вопроса на stackoverflow.
Но мой ответ был в основном реакцией на «не умеете готовить»- лично для меня такой оборот звучит как перекладывание проблем библиотеки (а какая из них без проблем?) на разработчика -мол это он дурак, неправильно использует и не важно что треть этого неправильного использования это баги qt или попытка их обойти, а вторая треть — внутренние изменения qt в результате чего код работавший в прошлой версии вдруг стал не правильным и не факт что это отражено в документации (с тем же комбобоксом мне ответили «ну вообще-то его надо использовать c popup», вот только ни в отличиях, ни в миграции на новую версию об этом не было ни слова). Ну а не менее трети оставим таки на разработчик сам дурак :)
По поводу "не умеете готовить" — я переводил свой домашний проект на Qt c 5.5 на 5.7 где-то в августе — ноябре 2016, проект реально небольшой и в основном переход был с Controls 1 на Controls 2 (заявлено что они должны работать вместе, хотя и не совместимы по API), результаты:
Изменили механизм освобождения ресурсов при пуше в stackview, теперь он сам дергает у компонетов createObject. Вот только про то что объект может быть создан еще и из строки с помощью Qt.createQmlObject() они забыли, такие объекты висят в памяти https://bugreports.qt.io/browse/QTBUG-55405
Дергаешь по старинке var component = Qt.createComponent() + component.createObject() и внутри у тебя FileDialog? Лови краш на второй или третий раз (багу не знаю, отписывался на форуме и в личке мне ответили что поправили), найти смог методом исключения
У тебя есть свойство прописанное внутри qml (пусть будет staticValue) и ты задаешь другое свойство с помощью stackView.push(component,{value:"two"}), казалось бы что тут может пойти не так? На практике значение в value попадает раньше чем в staticValue что может быть губительно если там есть вложенные объекты и передается в них нечто через функцию, а не через свойство (что, замечу, у меня было исключительно по причине другого бага Qt — в Combobox из controls 1 нельзя программно выбрать номер итема с пустой строкой https://bugreports.qt.io/browse/QTBUG-51698)
В целом у Qt имхо 2 проблемы:
Работа с памятью — имеется ручная работа в C++ и сборщик мусора в JS, но их взаимодействие написано криво — плюсовые объекты (например createQmlObject) не освобождаются сборщиком мусора сами собой, а js наоборот освобождаются. В итоге ты не можешь сохранить где-то js-объект между двумя вызовами формы, его приходится во что-то преобразовывать, а плюсовые объекты наоборот торчат в памяти. Причем работают с памятью правильно не всегда даже в самой библиотеке (см. 1 и, я так подозреваю, 3)
Бег впереди паровоза — в результате у них набирается куча багов (опять-таки 1, 2, см. примечание в 4, есть еще проблема с потерей фокуса после диалогов если ее только не поправили, периодически в логах ошибки в стиле "нет поля acccessory" внутри системных компонентов). Думаю, из-за этого же в библиотеке часто попадаются странные технические решения — пункт 4, повесить открытие списка комбобокса на пробел при том что нигде не запрещено его вводить (был такой баг до версии 5.4.1), QMap который на запрос неизвестного ей ключа вставляет его в себя с дефолтным значением, а ты потом долго и упорно пытаешься понять откуда у тебя в базу пришли пустые строки, при работе с файловой системой на винде часть компонентов использует пути вида /C:/my/path (драйвер sqlite, точнее ему этот слеш не вредит), а часть обычные виндовые (QFile), а qml-компоненты могут еще и file:// докинуть.
Причем ситуация с багами самой библиотеки это не особенность именно конкретной версии — мой проект медленно пишется по вечерам еще со времен Necessitas и я постоянно натыкаюсь на кучу мелких проблем, как верно отметили в одном из комментариев на хабре, Qt применительно к QML много лет стабильно сырой. Может, конечно, ситуация стала лучше в 5.8 (я ее еще не смотрел, но обязательно посмотрю), но что-то мне подсказывает что вряд ли.
Немножко не в тему, но увидел очередную вашу статью и вспомнился один вопрос — скажите, а дружит ли ваш анализатор с такой вещью как dependency injection и насколько дружит?
Поясню откуда вопрос возник — столкнулся я тут с тем что в iOs если использовать Typhoon (наиболее популярная DI библиотеку), то clang-analyzer (он же пункт Analyze в Xcode) перестает видеть взаимодействие с классами которые добавляются при помощи DI (оно и понятно — нет явной связи в коде), вот и стало интересно как с этим у вас? Вроде бы в C# DI тоже весьма популярная штука, а у вас есть поддержка этого языка, про С/С++ если честно не в курсе в этом аспекте.
Интересно, а если ситуация обратная — я взял рабочий ноутбук домой и что-то на нем сделал, тогда что? Или более сложная ситуация — я не делал на ноуте что-то от и до, а, скажем проверил как оно работает на другой операционке и, возможно, что-то поправил по мелочи, скажем, поставил размер шрифта по умолчанию в уже готовом в остальном проекте, при этом ноут изначально оказался дома по рабочей необходимости?
Я сталкивался с подобным наследством в медицинской области, где некоторые файлы были еще старше (там был сильнозапущеный принцип "работает — не трожь", помноженый на медицинскую специфику что любой код или либа по умолчанию считаются опасной и глючной). И проблем там была куча из-за этого, тот же кланг вообще не смог проанализировать или собрать проект из-за отсутствия -fpermissive и присутсвия в коде кнострукций void a(){ return 1;}
всякое бывает. Мне на одном собеседовании в крупной компании первым вопросом задали чем RISC от CISC отличается, при этом предполагалось что собеседование по iOS разработке (и уже были отдельные на общую грамотность, по алгоритмам и на написание кода на листочке) и ассемблера в их требованиях не было (это если не говорить про то что как бы проц ты вообще не можешь выбрать). Причем опыт разработки в этой области у компании есть (уточняю т.к. когда-то давно попадал в одну компанию где мне дали тест на проверку знаний C++, со словами «ну это же почти то же что и ObjC», но у них хотя бы опыта в этой области вроде как не было)
По профильным дисциплинам все было гораздо лучше и, как я потом понял увидев билеты к госам, даже лучше чем должно было быть по программе ибо в ней в 2008 году все еще отсутствовала цифровая техника как класс (реально, конечно, про нее рассказывали). Не могу сказать что все было вообще супер, но я это понял только постфактум, а студенту сравнивать особо не с чем было. В любом случае то что тогда давали иногда таки пригождается, а я ведь даже не на программиста учился коим сейчас работаю
А мы и не слушали, тупо прогуливали эту пару, благо препод настолько был уверен что мы идиоты что на зачете все успевали написать работу и за себя, и за отсутствующего товарища. А по поводу пойти в деканат/на кафедру — был у нас такой случай с параллельной группой, они сходили. По итогам препод остался тем же и сильно обиделся, ребята только проблем от этого огребли
А вообще по институтским воспоминаниям чем больше препод жалуется на то какие все студенты бездари, тем хуже он сам как специалист и препод. Попадались индивидуумы которые на рассказы какие мы идиоты тратили больше времени чем собственно на свой предмет, правда, по неправильным предметам типа экономики на инженерной специальности
А неясных моментов и багов на ровном месте (типа «не тот z поставили» или «забыли что наша библиотека имеет несколько способов создания объектов») в qt что-то в последнее время стало сильно больше, видимо вы правы про нокию (а может я старею и стал занудой, потому как субъективно кажется что это не только с qt такая проблема)
Хотя бывало что переиспользовали и отдельные части, скажем, когда все в целом то же самое, вид выглядит по другому для какого-то одного частного случая.
https://github.com/nst/objc_dep — строит граф зависимостей фаилов, можно оценить насколько все связано друг с другом в визуальной форме, а иногда и обнаружить что у тебя есть фаилы стоящие отдельно и ни с чем ни линкуемые
http://uncrustify.sourceforge.net/ — форматер, довольно известный и универсальный (работает с C, C++, C#, ObjectiveC, D, Java, Pawn и VALA)
https://pmd.github.io/pmd-5.4.1/usage/cpd-usage.html — поиск дублирующего кода, тоже для кучи всего, но есть и поиск для obj-c. Раньше он был через сторонний плагин, теперь похоже прямо в ванильной версии (каюсь — не пробовал, как-то раньше обходился старой версией, а в последнее время не использовал)
Ну и есть еще такой вопрос (который я уже пару раз задавал, но ответа пока не получил) — а вы проверяли как приведенные вами анализаторы ведут себя с тем же тайфуном? По моим наблюдениям, кланг попросту перестает проверять то что подключено через тайфун т.к. не видит свзяи между классами (оно и понятно — там линкуется-то только протокол, сам класс уже в рантайме оказывается связан).
По поводу же неразрешимой стены — ее практически нигде нет, вопрос в затратах на преодоление.
Но мой ответ был в основном реакцией на «не умеете готовить»- лично для меня такой оборот звучит как перекладывание проблем библиотеки (а какая из них без проблем?) на разработчика -мол это он дурак, неправильно использует и не важно что треть этого неправильного использования это баги qt или попытка их обойти, а вторая треть — внутренние изменения qt в результате чего код работавший в прошлой версии вдруг стал не правильным и не факт что это отражено в документации (с тем же комбобоксом мне ответили «ну вообще-то его надо использовать c popup», вот только ни в отличиях, ни в миграции на новую версию об этом не было ни слова). Ну а не менее трети оставим таки на разработчик сам дурак :)
По поводу "не умеете готовить" — я переводил свой домашний проект на Qt c 5.5 на 5.7 где-то в августе — ноябре 2016, проект реально небольшой и в основном переход был с Controls 1 на Controls 2 (заявлено что они должны работать вместе, хотя и не совместимы по API), результаты:
В целом у Qt имхо 2 проблемы:
Причем ситуация с багами самой библиотеки это не особенность именно конкретной версии — мой проект медленно пишется по вечерам еще со времен Necessitas и я постоянно натыкаюсь на кучу мелких проблем, как верно отметили в одном из комментариев на хабре, Qt применительно к QML много лет стабильно сырой. Может, конечно, ситуация стала лучше в 5.8 (я ее еще не смотрел, но обязательно посмотрю), но что-то мне подсказывает что вряд ли.
Немножко не в тему, но увидел очередную вашу статью и вспомнился один вопрос — скажите, а дружит ли ваш анализатор с такой вещью как dependency injection и насколько дружит?
Поясню откуда вопрос возник — столкнулся я тут с тем что в iOs если использовать Typhoon (наиболее популярная DI библиотеку), то clang-analyzer (он же пункт Analyze в Xcode) перестает видеть взаимодействие с классами которые добавляются при помощи DI (оно и понятно — нет явной связи в коде), вот и стало интересно как с этим у вас? Вроде бы в C# DI тоже весьма популярная штука, а у вас есть поддержка этого языка, про С/С++ если честно не в курсе в этом аспекте.
То есть по умолчанию если такого пункта в договоре не было, то и предъявить нечего?
Интересно, а если ситуация обратная — я взял рабочий ноутбук домой и что-то на нем сделал, тогда что? Или более сложная ситуация — я не делал на ноуте что-то от и до, а, скажем проверил как оно работает на другой операционке и, возможно, что-то поправил по мелочи, скажем, поставил размер шрифта по умолчанию в уже готовом в остальном проекте, при этом ноут изначально оказался дома по рабочей необходимости?
Я сталкивался с подобным наследством в медицинской области, где некоторые файлы были еще старше (там был сильнозапущеный принцип "работает — не трожь", помноженый на медицинскую специфику что любой код или либа по умолчанию считаются опасной и глючной). И проблем там была куча из-за этого, тот же кланг вообще не смог проанализировать или собрать проект из-за отсутствия -fpermissive и присутсвия в коде кнострукций void a(){ return 1;}