Скорее Сталинград

Тогда модулей не видать. И скоро будет откат всех фич и захват лута.

Вернемся к divine C

интересно, кому и сколько надо заплатить, чтобы эта вакханалия кончилась. "Within C++, there is a much smaller and clearer language struggling to get out" — это сколько лет назад было сказано?

интересно, кому и сколько надо заплатить, чтобы эта вакханалия кончилась. "Within C++, there is a much smaller and clearer language struggling to get out" — это сколько лет назад было сказано?

какая вакханалия? с модулями?

С модулями всё ок - их нет )))

с с++11+

C++11 это даже язык программирования, а не система издевательств над программистами

интересно, кому и сколько надо заплатить, чтобы эта вакханалия кончилась. "Within C++, there is a much smaller and clearer language struggling to get out" — это сколько лет назад было сказано?

Про какое из подмножеств языка это сказано?))

Про какое из подмножеств языка это сказано?))

Про перевод числа в строку, я полагаю

Про какое из подмножеств языка это сказано?))

ну вот сегодня я узнал, что есть std::addressof и зачем он нужен

(это только один маленький пример, конечно)

ну вот сегодня я узнал, что есть std::addressof и зачем он нужен

ну вот качественная штука

Возникла вдруг на верхах инициатива массово вкрутить в проект Cppcheck. Причем вкрутить не так, чтобы по ночам на CI падали сборки от 100500 варнингов накопившихся за много лет, а чтобы анализатор давал прогеру по рукам за привнесение новых бяк и отправлял исправлять. Правда пока не сошлись во мнениях - в какой момент это лучше делать? При сборке проекта? При коммите? При отправке коммита на ревью? Кто уже практикует такую автоматику, у вас как?

А я недавно вычитал про std::launder, кажется куда более весёлая.

std::launder из министерства любви, обожания и реализации контейнеров, которые уже реализованы в 17

А я недавно вычитал про std::launder, кажется куда более весёлая.

про это я уже успел забыть...

очень круто портировать в 14 стандарт без launder

а по факту зафиксированы случаи проявления этого UB отличным от ожидаемого образом?

Возникла вдруг на верхах инициатива массово вкрутить в проект Cppcheck. Причем вкрутить не так, чтобы по ночам на CI падали сборки от 100500 варнингов накопившихся за много лет, а чтобы анализатор давал прогеру по рукам за привнесение новых бяк и отправлял исправлять. Правда пока не сошлись во мнениях - в какой момент это лучше делать? При сборке проекта? При коммите? При отправке коммита на ревью? Кто уже практикует такую автоматику, у вас как?

я бы на коммите проверял

А админы шустрые

А админы шустрые

10 seconds flat!

Возникла вдруг на верхах инициатива массово вкрутить в проект Cppcheck. Причем вкрутить не так, чтобы по ночам на CI падали сборки от 100500 варнингов накопившихся за много лет, а чтобы анализатор давал прогеру по рукам за привнесение новых бяк и отправлял исправлять. Правда пока не сошлись во мнениях - в какой момент это лучше делать? При сборке проекта? При коммите? При отправке коммита на ревью? Кто уже практикует такую автоматику, у вас как?

Вот только старье подчистить придется, иначе может быть неприятно

Возникла вдруг на верхах инициатива массово вкрутить в проект Cppcheck. Причем вкрутить не так, чтобы по ночам на CI падали сборки от 100500 варнингов накопившихся за много лет, а чтобы анализатор давал прогеру по рукам за привнесение новых бяк и отправлял исправлять. Правда пока не сошлись во мнениях - в какой момент это лучше делать? При сборке проекта? При коммите? При отправке коммита на ревью? Кто уже практикует такую автоматику, у вас как?

Clang analyzer

Cppcheck бывает врёт

Вот только старье подчистить придется, иначе может быть неприятно

Пока что нашли какой то веселый скрипт, который не то делает дифф сежду набором вврнингов до и после, то ли вырезает варнинги, адресованные "лишними" к диффу сборками

а шланг поклялся говорить только правду и ничего кроме правды?

в языке с достаточно слабой системой типов все или врут, или молчат, как партизаны

Пока что нашли какой то веселый скрипт, который не то делает дифф сежду набором вврнингов до и после, то ли вырезает варнинги, адресованные "лишними" к диффу сборками

Ну такое. Если у меня копипаста с места А в место Б проекта не пройдет, я буду чем свет стоит материть

Возникла вдруг на верхах инициатива массово вкрутить в проект Cppcheck. Причем вкрутить не так, чтобы по ночам на CI падали сборки от 100500 варнингов накопившихся за много лет, а чтобы анализатор давал прогеру по рукам за привнесение новых бяк и отправлял исправлять. Правда пока не сошлись во мнениях - в какой момент это лучше делать? При сборке проекта? При коммите? При отправке коммита на ревью? Кто уже практикует такую автоматику, у вас как?

Активисты "на этапе сборки" упирают на гуляющий по рукам старый скрипт, который позволяет cppcheck запускать как таргет сборки в qt creator, и все ошибки можно подсвечивать и даблкликать для перехода - давайте дескать его прямо в сам сборщик и встроим

мне больше интересно, как решается проблема со временем анализа

Ну такое. Если у меня копипаста с места А в место Б проекта не пройдет, я буду чем свет стоит материть

Так наоборот же здорово, и копипасту побороло, и место А заодно поправили если есть возможность)

мне больше интересно, как решается проблема со временем анализа

Анализируется только измененный файл, прожект-вайд анализом приходится платить - впрочем его все равно никто завести так и не смог(

PBYTE - это обычный byte *?

PBYTE - это обычный byte *?

это BYTE*

Гоу за пивом.. Футбол скоро.

это BYTE*

Оукей, а BYTE разве не byte?)

Оукей, а BYTE разве не byte?)

А такой тип есть в C++?

ага, std::byte =)

ну std::byte и byte это разные имена

ага, std::byte =)

О бля во точно, он в std лежит

и BYTE это обычно unsigned char

а std::byte это enum class

а std::byte это enum class

Вот это для меня открытие. Но эквивалент PBYTE (BYTE *) - это unsigned char *? Получается так.

:)

а std::byte это enum class

И что это значит для пользователя?

Возникла вдруг на верхах инициатива массово вкрутить в проект Cppcheck. Причем вкрутить не так, чтобы по ночам на CI падали сборки от 100500 варнингов накопившихся за много лет, а чтобы анализатор давал прогеру по рукам за привнесение новых бяк и отправлял исправлять. Правда пока не сошлись во мнениях - в какой момент это лучше делать? При сборке проекта? При коммите? При отправке коммита на ревью? Кто уже практикует такую автоматику, у вас как?

При попытке мёрджа в транк

у нас куча тестов крутится которые падают если человек пытается в транк залить говно

И что это значит для пользователя?

что std::is_same_v<std::byte, unsigned char> == false

enum class byte : unsigned char {} ; (since C++17)

Крч разобрался, изи Месяц просто не прогал на плюсах

что std::is_same_v<std::byte, unsigned char> == false

Логично как бэ

Логично как бэ

ну а что ты тогда спросил?

Наверное глупость я понял почему это енум а не тайп алиас

При попытке мёрджа в транк

Думаю не вариант - 8 репозиториев без гитфлоу, с 2-3 транками, но можно попробовать

Возникла вдруг на верхах инициатива массово вкрутить в проект Cppcheck. Причем вкрутить не так, чтобы по ночам на CI падали сборки от 100500 варнингов накопившихся за много лет, а чтобы анализатор давал прогеру по рукам за привнесение новых бяк и отправлял исправлять. Правда пока не сошлись во мнениях - в какой момент это лучше делать? При сборке проекта? При коммите? При отправке коммита на ревью? Кто уже практикует такую автоматику, у вас как?

мы практикуем. У нас такой подход - код заливается на ревью, там на него набрасываются билд боты + бот с чекерами (cppcheck, clang-tidy, кое-что ещё). Если анализатор находит хоть какую-то новую проблему - ставит на ревью -1

Clang analyzer

внезапно и он не идеален. так что лучше использовать оба

анализируется естественно весь файл целиком?

анализируется естественно весь файл целиком?

нет. дифф

типа сам файл, но варнинги выдаются только на дифф

т.е. из варнингов остаются только те, где проблемные строчки приходятся на один из интервалов диффа?

т.е. из варнингов остаются только те, где проблемные строчки приходятся на один из интервалов диффа?

да

чтобы старое и тебя не касающееся не лезло. Ну и у нас ещё есть копипаст бот

который ищет копипасту, и если находит, указывает, что мол копипаста, сэр и надо бы исправить

да

хм, получается, теоретически возможна ситуация, когда код в рамках диффа без ворнингов, но создает новые ворнинги за пределами диффа (в неизменившихся местах)? Например, присваивание переменной делает последующий if always true/false.

гораздо надёжнее было бы прочекать старый файл и получить список ворнингов

прочекать новый и получить такой список

а потом сделать дифф списков ворнингов

разве нет?

Может это и подрузомевается под дифом?

да, скорее всего

а потом сделать дифф списков ворнингов

такой вариант у нас тоже предлагался) но найденный скрипт и @zamazan4ik говорят о другом

а есть группа людей ревесом занимающихся? или может кто подсказать, почему нельзя изменять(двигать, раcширять) ELF файлы с типом ET_REL

а есть группа людей ревесом занимающихся? или может кто подсказать, почему нельзя изменять(двигать, раcширять) ELF файлы с типом ET_REL

@proasm

кто был на митапе Марка, как было?

кто был на митапе Марка, как было?

Ну... В общем наверно я могу высказать коллективное мнение, что всем понравилось, но не хватало глубинных технических деталей. Презентация была достаточно поверхностна в техническом плане, не было деталей. Как положительный эффект безусловно было лишний раз привлечено внимание к Conan, что есть такой и можно юзать, поговорили по английски, поели пиццы, все такое. Но мне показалось что примерно половина или по крайней мере треть из аудитории уже была хотя бы базово знакома с Conan и хотела что-то более глубоко узнать. А так здорово очень. Они ещё и плагин для CLion презентовали...

кто был на митапе Марка, как было?

Может кто-то ещё что-то скажет

Ну... В общем наверно я могу высказать коллективное мнение, что всем понравилось, но не хватало глубинных технических деталей. Презентация была достаточно поверхностна в техническом плане, не было деталей. Как положительный эффект безусловно было лишний раз привлечено внимание к Conan, что есть такой и можно юзать, поговорили по английски, поели пиццы, все такое. Но мне показалось что примерно половина или по крайней мере треть из аудитории уже была хотя бы базово знакома с Conan и хотела что-то более глубоко узнать. А так здорово очень. Они ещё и плагин для CLion презентовали...

всё понял. Спасибо!

кто был на митапе Марка, как было?

Это был хороший доклад о возможностях Conan. в принципе, от PM я ожидал меньшего, а здесь и live demo и достаточно широкий спект освещения. Но один вопрос необходимо включить в доклады по продвижению: с чего начать разработчику, чем руководствоваться, какие шаги пройти для написания своего рецепта и портирования библиотеки желательно с примерами патчинга и т.п.

кто был на митапе Марка, как было?

Было хорошо, но я бы рассказал про другое, делался упор на скорость сборки, давался пример на внедрение сборки по рецепту, но не было рассказано про те же генераторы, а с них все начинается

Это был хороший доклад о возможностях Conan. в принципе, от PM я ожидал меньшего, а здесь и live demo и достаточно широкий спект освещения. Но один вопрос необходимо включить в доклады по продвижению: с чего начать разработчику, чем руководствоваться, какие шаги пройти для написания своего рецепта и портирования библиотеки желательно с примерами патчинга и т.п.

Вот да, мысли сходятся

А есть видео или презентация?

Да мы ещё своих про Conan запилим!