Ничего себе! Как это вам удалось? Мне Fusion дарили, одной кассеты на 2 бритья хватало от силы. К слову, у меня довольно скудная растительность на лице, бороду окладистую вырастить не получится.
Так что пока перешел снова на одноразовые станки по 10 рублей, выходит дешевле, чем 4 кассеты за штуку с лишним.
Я вообще думаю, что самую эффективную скорость по рефлексии можно получить с помощью кодогенерации.
Но я рекомендую почитать еще вот эту статью woboq.com/blog/reflection-in-cpp-and-qt-moc.html
Авторы задумались о том, какие возможности стоит добавить в компилятор C++, чтобы генератор moc был не нужен.
Меня как-то ревьюил опытный коллега, который у нас не работает уже. После этого я к ревью не обращался.
-Много двойных пробельных строк;
-Не отбиты пробелами вызовы функций;
-Не все методы с Doxygen комменнтами;
-Названия классов видите ли надо с литеры C начинать, а то вроде как непонятно где класс а где метод (у меня подсветка кода, мне все понятно).
Я спросил его «ну а архитектура-то как?» он «ну я хз, я не понял как оно работает. вроде норм.»
Последнее как раз неинтересно. Если ты с детства пользуешься фаренгейтами, запомнил и «ощутил» основные числа, почему тебе должно быть удобно и понятно мерить в цельсиях? Шкала по F от 0 до 100 куда больше укладывается в повседневное использование (в теплом климате >= -17) без частого привлечения отрицательных температур.
Ну кельвины да, линейно равны цельсиям, поэтому в далекой перспективе уж лучше и тем другим перейти на абсолютную шкалу да и все)
«По области ожидается 300 градусов, небольшой дождь.» никаких плюсов и минусов.
Ребята, поделитесь опытом, как вы потом обновляете скриншоты в документации, когда интерфейс меняется?
И что делать, если скриншот уже был обработан (добавлены красные рамки, стрелки, тени, обрезаны края и тп)?
У нас просто это довольно механически делается, мне кажется это немного неправильно…
Мне сейчас довольно тяжело будет снова настраивать проекты под студию. У нас для всех проектов, и виндовых, и линуксовых используется система сборки QBS. Но я слежу за вашим проектом внимательно, и обязательно попробую еще раз, как только будет чуть посвободнее график (сейчас только срочняки в очереди).
Кстати, раз на то пошло — по результатам разных анализов стат.анализаторов (pvs, cppcheck, clang) — самая распространенная ошибка в моем проекте — неинициализированное поле (в том числе указатель). потенциальное *null лишь на втором месте.
Таких ошибок, как «эффект последней строки» или «эффект копипасты», почему-то ненаблюдалось. Обычно они очень быстро вылазят при первом же прогоне/тесте.
Ну еще довольно частые незначительные ошибки смешниваия int/size_t/uint32_t при доступе к контейнерам (при сериализации — нет).
Вот такая статистика =)
Да, ни один из стат анализаторов, к сожалению, не нашел ошибки, которая реально могла бы привести к порче/потере данных (потенциально, при каком-то дальнейшем изменении кода — да). Нет, не то что у нас прямо так идеально код пишут, я считаю, что то что было найдено- тоже полезно. Но больше с точки зрения прикладной диагностики принес нам valgrind (да, я читал ваши статьи про отличия динамического и статического анализа и понимаю что они мало где пересекаются).
Раз уж я рассказываю о своем опыте, опишу самый распространенный класс ошибок, найденный valgrind — выделяется память, сохраняется указатель, и потом передается через очень долгие и тернистые пути в другое место. Затем (МНОГОПОТОЧНОСТЬ!) в исходном месте он удаляется, и в новом естественном может иногда произойти доступ к уже удаленной памяти. Статический анализатор такое понять не в состоянии. После пары таких косяков я стал жестко переходить на shared+weak_ptr. помогло.
P.S. посмотрел прямо сейчас CLOC-ом, 320k sloc без 3rdparty, 40% — хедеры.
Да, наверное, Вы правы. У меня небольшой проект, около 150тысяч С++ кода, и когда я скачивал ваш анализатор год назад, он находил только предупреждения 3 уровня.
habrahabr.ru/post/248331
Так что пока перешел снова на одноразовые станки по 10 рублей, выходит дешевле, чем 4 кассеты за штуку с лишним.
Но я рекомендую почитать еще вот эту статью
woboq.com/blog/reflection-in-cpp-and-qt-moc.html
Авторы задумались о том, какие возможности стоит добавить в компилятор C++, чтобы генератор moc был не нужен.
Очень интересный черновик по рефлексии в С++
-Много двойных пробельных строк;
-Не отбиты пробелами вызовы функций;
-Не все методы с Doxygen комменнтами;
-Названия классов видите ли надо с литеры C начинать, а то вроде как непонятно где класс а где метод (у меня подсветка кода, мне все понятно).
Я спросил его «ну а архитектура-то как?» он «ну я хз, я не понял как оно работает. вроде норм.»
Ну кельвины да, линейно равны цельсиям, поэтому в далекой перспективе уж лучше и тем другим перейти на абсолютную шкалу да и все)
«По области ожидается 300 градусов, небольшой дождь.» никаких плюсов и минусов.
Думаю, НАСТОЛЬКО небольшое, что они никогда не заметят.
И что делать, если скриншот уже был обработан (добавлены красные рамки, стрелки, тени, обрезаны края и тп)?
У нас просто это довольно механически делается, мне кажется это немного неправильно…
Посмотрю на досуге.
Кстати, раз на то пошло — по результатам разных анализов стат.анализаторов (pvs, cppcheck, clang) — самая распространенная ошибка в моем проекте — неинициализированное поле (в том числе указатель). потенциальное *null лишь на втором месте.
Таких ошибок, как «эффект последней строки» или «эффект копипасты», почему-то ненаблюдалось. Обычно они очень быстро вылазят при первом же прогоне/тесте.
Ну еще довольно частые незначительные ошибки смешниваия int/size_t/uint32_t при доступе к контейнерам (при сериализации — нет).
Вот такая статистика =)
Да, ни один из стат анализаторов, к сожалению, не нашел ошибки, которая реально могла бы привести к порче/потере данных (потенциально, при каком-то дальнейшем изменении кода — да). Нет, не то что у нас прямо так идеально код пишут, я считаю, что то что было найдено- тоже полезно. Но больше с точки зрения прикладной диагностики принес нам valgrind (да, я читал ваши статьи про отличия динамического и статического анализа и понимаю что они мало где пересекаются).
Раз уж я рассказываю о своем опыте, опишу самый распространенный класс ошибок, найденный valgrind — выделяется память, сохраняется указатель, и потом передается через очень долгие и тернистые пути в другое место. Затем (МНОГОПОТОЧНОСТЬ!) в исходном месте он удаляется, и в новом естественном может иногда произойти доступ к уже удаленной памяти. Статический анализатор такое понять не в состоянии. После пары таких косяков я стал жестко переходить на shared+weak_ptr. помогло.
P.S. посмотрел прямо сейчас CLOC-ом, 320k sloc без 3rdparty, 40% — хедеры.