В общем я писал чекеры для tidy, так что спор чисто терминлоголический

ой, извините, фронтенд

В общем я писал чекеры для tidy, так что спор чисто терминлоголический

ну я тоже писал, и что? я не согласен, что написание чего-то в clang-tidy равно по сложности патчингу шланга

В случае с обработкой атрибута сложность будет равна. Плагин для clang, или чекер для tidy, код будет почти тот же самый

тот же самый frontend action можно прикрутить плагином к компилятору

и нафига это пихать в сам компилятор, если есть уже специальное место, которое для этого предназанчено?

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

а чтобы чекер собрать и подключить - нужно ли собирать руками clang и всё остальное?

проще интегрировать в билд

а чтобы чекер собрать и подключить - нужно ли собирать руками clang и всё остальное?

нужно собрать clang-tidy

проще интегрировать в билд

запуск clang-tidy добавить в билд может быть и сложно, если у вас к этому моменту ничего не настроено. Для меня монопенисуальная сложность

В общем спор бессмысленный, продолжать не буду

ок \thread

а чтобы чекер собрать и подключить - нужно ли собирать руками clang и всё остальное?

В принципе если интегрировать свой код в билд систему llvm то можно использовать всякие удобные cmake функции которые они там написали

но можно и отдельным проектом, примерно так https://heejune.me/2016/08/17/build-your-own-clang-example-outside-of-the-llvm-source-tree/comment-page-1/

я просто пытаюсь понять - что проще сделать, чекер на для tidy или плагин к clang, при условии что на машине clang установлен тупо из репозитория скажем убунты, и никто никогда clang не собирал.

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

имхо, лучше взять свежий clang и собрать из исходников

имхо, лучше взять свежий clang и собрать из исходников

а потом собирать проект старым clang, а чекеры запускать от нового?

я просто пытаюсь понять - что проще сделать, чекер на для tidy или плагин к clang, при условии что на машине clang установлен тупо из репозитория скажем убунты, и никто никогда clang не собирал.

1) Если clang-tidy, то там добавишь по инструкции свой чекер, потом билдишь сборку clang-tidy и отдаёшь её куда тебе надо 2) Если интегрировать в компилятор, то патчишь компилятор и отдаёшь куда тебе надо

а потом собирать проект старым clang, а чекеры запускать от нового?

А зачем, собираешь новый и переключаешься целиком на него

А зачем, собираешь новый и переключаешься целиком на него

лол, это же так легко сделать

просто взять и апдейтнуть компилятор

а потом собирать проект старым clang, а чекеры запускать от нового?

какой размер у тебя кодовой базы?

просто взять и апдейтнуть компилятор

А что сложно? У меня на работе лохматый SLES11, при этом я работаю с clang из транка

А зачем, собираешь новый и переключаешься целиком на него

мигрировать весь проект на другой компилятор вот так, ради одного чекера, это как-то слишком.

А что сложно? У меня на работе лохматый SLES11, при этом я работаю с clang из транка

1) Проблема не в этом, а втом, что нельзя так просто мигрировать ПРОЕКТ на новый компилятор

какой размер у тебя кодовой базы?

около миллиона строк

мигрировать весь проект на другой компилятор вот так, ради одного чекера, это как-то слишком.

Ну тогда можешь собирать старым компилятором, если он конечно с++11 поддерживает

1) Проблема не в этом, а втом, что нельзя так просто мигрировать ПРОЕКТ на новый компилятор

я не понял контекста, думал что человек хочет просто поиграться с написаниями чекеров с нуля

проблема не только в сборке. Проблема в выплывании новых UB, например

проблема не только в сборке. Проблема в выплывании новых UB, например

именно.

Ваш код как-то работал на старом компиляторе, потому что спрятанное UB не стреляло просто. а тут вы апдейтнули компилятор и код начал стрелять. И вот такие вещи очень дорого фиксить

я не понял контекста, думал что человек хочет просто поиграться с написаниями чекеров с нуля

хочет поиграться, а потом применить с пользой, скажем так.

хочет поиграться, а потом применить с пользой, скажем так.

для поиграться возьми транк LLVMб и там попробуй, что тебе надо. а потом уже по результат игрищ решишь, нужно ли оно вам

в принципе коллега соббирает свежий clang с помощью лохматого gcc 5.3 , так что никаких проблем

1) Это совсем отдельная тема 2) Кто-то сказал, что у поциента всё это есть? 3) Не пойму, как CI и кроссбилд спасёт от описанной мною проблемы. Уменьшить шансы - пожалуй, спасти - нет

зачем лезть в компилятор, если для этого уже придуман clang-tidy?

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

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

?

это всё круто, но далеко не везде так настроено (к сожалению). И это всё равно не спасает от опасности апгрейда на новый компилятор. Здесь проблемы не портируемости, а что код у тебя с UB. и когда он рванёт, ты не знаешь. А при смене компилятора (в том числе и версии) шанс взрыва увеличивается

?

ну смотри, концептуально если эта проверка работает, что нужен вспомогательный класс std::scope_mark<T = /*unspecified local type*/>, пушо объявлять структуру на входе каждой функции это ппц наркомания

код с UB - для бизнеса не проблема. А вот нерабочая прграмма - проблема ?

если у вас несколько сот тысяч строк кода, UB там где-то точно есть.

код с UB - для бизнеса не проблема. А вот нерабочая прграмма - проблема ?

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

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

ну так проблемой в данном случае является нерабочая программа. И так то неважно, что к этому привело - это надо фиксить.

если вспомнить все особенности С++ от MS, то тут будет больно не только от UB

очень больно

если вспомнить все особенности С++ от MS, то тут будет больно не только от UB

да. если разрабатывать и билдить только под компилятором МС долгое время, то потом будет очень больно

это который clang/c2 ?

ну, собственно полно проектов где так и делают. один компилятор, одна система, одна вижуалстудия!

https://twitter.com/stephantlavavej/status/871861920315211776?lang=ru

если вспомнить все особенности С++ от MS, то тут будет больно не только от UB

не знаю, пока самый ужас в С++ как раз из ISO C++ а не от MS :)

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

не знаю, пока самый ужас в С++ как раз из ISO C++ а не от MS :)

дыа, даёшь static переменные в функциях по стандарту, которые МС заботливо оборачивает в thread_local, чтобы не приходилось городить огород для многопоточности!)

^

дыа, даёшь static переменные в функциях по стандарту, которые МС заботливо оборачивает в thread_local, чтобы не приходилось городить огород для многопоточности!)

это где? у меня лично стрессы находили data race на статических переменных функций

и половина кода сломается, если это будет

потому что весь dependency injection работает через синглтоны в статических переменных

ну, собственно полно проектов где так и делают. один компилятор, одна система, одна вижуалстудия!

Хотите #holywar?

Хотите #holywar?

на тему?

это где? у меня лично стрессы находили data race на статических переменных функций

было два бабаха в си-подобных функциях, первый сходу не вспомню, второй - localtime() работает с глобальной time_struct, который при этом делит с gmttime(), из-за чего в каких-то совершенно уникальных случаях взрывался кусок старого календаря

на тему?

я вам популярно объясню, почему я так делаю

например, что я в кино водил писать код без __super или делать гениальные workaround, ставить макросы вместо pragma once и так далее

было два бабаха в си-подобных функциях, первый сходу не вспомню, второй - localtime() работает с глобальной time_struct, который при этом делит с gmttime(), из-за чего в каких-то совершенно уникальных случаях взрывался кусок старого календаря

ну, это уж как-то совсем...

*_r-варианты на той же странице описаны...

не исключаю, что десять лет назад, когда всё это писалось, про _r варианты вижак и слыхом не слыхивал)

например, что я в кино водил писать код без __super или делать гениальные workaround, ставить макросы вместо pragma once и так далее

эта прагма же всеми поддерживается.

а, тогда пардон. я программирую вдвое короче )

в catch[2] можно тесты поместить в произвольную функцию? вместо TEST_CASE( "Factorials are computed", "[factorial]" ){...} сделать void x() { CHECK(1 == 1); }

Это закос под Беркуса?)

в catch[2] можно тесты поместить в произвольную функцию? вместо TEST_CASE( "Factorials are computed", "[factorial]" ){...} сделать void x() { CHECK(1 == 1); }

теоретически проверки туда засунуть можно если постараться, ЕМНИП, но на практике эта функция просто не будет вызываться при запуске тестов, т.к TEST_CASE её регистрирует в тест-раннере

Это закос под Беркуса?)

сложный вопрос

эта прагма же всеми поддерживается.

а __if_exists тоже?)

А где pragma once не поддерживается? Недавно наткнулся на это и немног удивился https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.cbcdg01/msg-CCN8735.htm

А где pragma once не поддерживается? Недавно наткнулся на это и немног удивился https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.cbcdg01/msg-CCN8735.htm

IBM это вообще какой-то неземной уровень.

IBM это вообще какой-то неземной уровень.

?

Всем привет! Народ, подскажите, я сам javascript-разработчик и в js автоматическая сборка мусора но мне стало интересно - как в языках в частности в плюсах с этой ручной сборкой мусора решается проблема аллокации нового объекта и фрагментации памяти? Я тут немного представил как мог бы работать механизм аллокации - подскажите прав я или нет? Я правильно понимаю что для того чтобы с каждым вызовом new не делать медленный системный вызов аллокации происходит одноразовая аллокация большого участка памяти а удаление объекта приводит к просто пометке как "свободный" конкретного участка памяти и происходит хранение таких участков в связанном списке - указатель на голову и хвост хранятся в глобальных переменных, новый удаленный участок добавляется к хвосту связанного списка а когда нужно аллоцировать новый объект то просто берем новый свободный участок из глобальной переменной указывающую на голову связанного списка? А как тогда происходит аллокация объектов разного размера - будет создан отдельный связанный список свободных участков памяти для каждого размера объекта? Или объекты разного размера будут храниться в участках памяти с кратными между собой размерами чтобы на свободном участке большого размера можно было аллоцировать много объектов меньшего размера? И неясно как решается проблема фрагментации памяти - что если например есть приложение где можно создавать и удалять сущности разного размера - получается рано или поздно появится ситуация когда новый объект создать невозможно потому что непрерывного участка такого размера нет зато более мелких участков памяти достаточно. Как вы в плюсах решаете такую проблему?

ос внизу может дефрагментировать участки

ос внизу может дефрагментировать участки

Мне кажется, он имеет ввиду кастомные аллокаторы

Всем привет! Народ, подскажите, я сам javascript-разработчик и в js автоматическая сборка мусора но мне стало интересно - как в языках в частности в плюсах с этой ручной сборкой мусора решается проблема аллокации нового объекта и фрагментации памяти? Я тут немного представил как мог бы работать механизм аллокации - подскажите прав я или нет? Я правильно понимаю что для того чтобы с каждым вызовом new не делать медленный системный вызов аллокации происходит одноразовая аллокация большого участка памяти а удаление объекта приводит к просто пометке как "свободный" конкретного участка памяти и происходит хранение таких участков в связанном списке - указатель на голову и хвост хранятся в глобальных переменных, новый удаленный участок добавляется к хвосту связанного списка а когда нужно аллоцировать новый объект то просто берем новый свободный участок из глобальной переменной указывающую на голову связанного списка? А как тогда происходит аллокация объектов разного размера - будет создан отдельный связанный список свободных участков памяти для каждого размера объекта? Или объекты разного размера будут храниться в участках памяти с кратными между собой размерами чтобы на свободном участке большого размера можно было аллоцировать много объектов меньшего размера? И неясно как решается проблема фрагментации памяти - что если например есть приложение где можно создавать и удалять сущности разного размера - получается рано или поздно появится ситуация когда новый объект создать невозможно потому что непрерывного участка такого размера нет зато более мелких участков памяти достаточно. Как вы в плюсах решаете такую проблему?

Очень рекомендую доклад Фёдора Короткого с cpp russia 2018, называется "Память - идеальная абстракция". Он там рассказывает про то, как jmalloc внутри устроен. Про подсистемы малых и больших аллокаций, структуры данных, которые там используются и прочее

ну, и за ним следом тогда: https://www.youtube.com/watch?v=dFquxC6qTSA

Ещё можно почитать, как винда пытается с этим бороться: https://docs.microsoft.com/en-us/windows/desktop/memory/low-fragmentation-heap

Всем привет! Народ, подскажите, я сам javascript-разработчик и в js автоматическая сборка мусора но мне стало интересно - как в языках в частности в плюсах с этой ручной сборкой мусора решается проблема аллокации нового объекта и фрагментации памяти? Я тут немного представил как мог бы работать механизм аллокации - подскажите прав я или нет? Я правильно понимаю что для того чтобы с каждым вызовом new не делать медленный системный вызов аллокации происходит одноразовая аллокация большого участка памяти а удаление объекта приводит к просто пометке как "свободный" конкретного участка памяти и происходит хранение таких участков в связанном списке - указатель на голову и хвост хранятся в глобальных переменных, новый удаленный участок добавляется к хвосту связанного списка а когда нужно аллоцировать новый объект то просто берем новый свободный участок из глобальной переменной указывающую на голову связанного списка? А как тогда происходит аллокация объектов разного размера - будет создан отдельный связанный список свободных участков памяти для каждого размера объекта? Или объекты разного размера будут храниться в участках памяти с кратными между собой размерами чтобы на свободном участке большого размера можно было аллоцировать много объектов меньшего размера? И неясно как решается проблема фрагментации памяти - что если например есть приложение где можно создавать и удалять сущности разного размера - получается рано или поздно появится ситуация когда новый объект создать невозможно потому что непрерывного участка такого размера нет зато более мелких участков памяти достаточно. Как вы в плюсах решаете такую проблему?

Про new - вызов все равно долгий, потому что в malloc сложные требования Про фрагментацию памяти - эта проблема достаточно надолго забыта, потому что в x64 виртуальной памяти очень много