AS
ну, так то да. но тут будут дополнительная (существенная) нагрузка на CI процесс
с одной стороны да, с другой стороны исправлять ошибки значительно дороже потом чем сразу.
Size: a a a
2020 May 04
AR
богемному GC, насколько я помню, в плюсах тех же, нужно явным образом указывать за чем следить, а за чем нет. Просто взять и включить его для программы которая не была писана с его учетом - не выйдет.
Выйдет же, он консервативный. Просто дёрнет free на всех областях, куда нет указателей (ничего похожего на указатели). Деструкторы он, конечно, не вызовет. Вообще не уверен, что там есть финализаторы
AR
Он из коробки сканит data, bss и стек
AV
с одной стороны да, с другой стороны исправлять ошибки значительно дороже потом чем сразу.
ну, смотри. так у тебя билд каждой ветки каждого разработчика шел по 2 часа, теперь идет по 8. Грубо говоря, тебе нужно в 4 раза больше машин в инфраструктуре, чтобы всё было просто плохо, а не совсем ужасно. Это конкретные деньги и прямо сейчас. И всё равно будет хуже - пока твой билд соберется, мастер уже убежит например.
И это мы еще к тестам не приступили. Ускорится ли от этого разработка? Я не уверен.
И это мы еще к тестам не приступили. Ускорится ли от этого разработка? Я не уверен.
AS
правильно. поэтому не нужен нам никакой статический анализ
The -Wlifetime warnings implemented in clang это как раз кусок статического анализатора который должен быть частью компилятора и которы туда постпенно заползает.
AV
То есть как минимум строгие и сложные проверки на этапе компиляции должны быть отключабельны.
AV
Выйдет же, он консервативный. Просто дёрнет free на всех областях, куда нет указателей (ничего похожего на указатели). Деструкторы он, конечно, не вызовет. Вообще не уверен, что там есть финализаторы
ты пробовал его использовать? я пробовал ммм.. лет 12 назад. И у меня смутные воспоминания, что для плюсов там оберточки специальные были. Я тогда разочаровался и ушел.
AR
Пробовал пару лет назад, но по фану, так что не совсем считается. Достаточно сделать s/malloc/GC_MALLOC/.
AV
Пробовал пару лет назад, но по фану, так что не совсем считается. Достаточно сделать s/malloc/GC_MALLOC/.
эмм.. это ж не считается 😊 то есть это считай переписываени. а также нужно будет с new разобраться
AS
То есть как минимум строгие и сложные проверки на этапе компиляции должны быть отключабельны.
безусловно строгие и сложные только опционально или в качестве сторонней тулзы.
AR
Но я только в plain c пробовал. Бтв, пишут, что есть и финалайзеры и плюсовый интерфейс. https://www.hboehm.info/gc/gcinterface.html
AV
Но я только в plain c пробовал. Бтв, пишут, что есть и финалайзеры и плюсовый интерфейс. https://www.hboehm.info/gc/gcinterface.html
есть. но прога должна быть под эту богему специально написана. просто взять и пересобрать или включить его даже без пересборки - не выйдет. ну, или я не нашел как.
AR
эмм.. это ж не считается 😊 то есть это считай переписываени. а также нужно будет с new разобраться
Ну я тут говорю с позиции, что не понятно чем conservtive gc в d лучше чем boehm для c/c++.
AV
Ну я тут говорю с позиции, что не понятно чем conservtive gc в d лучше чем boehm для c/c++.
тем, что тип GC ты можешь выбирать независимо от написания самой проги.
AV
максимум - нужно будет пересобрать.
AR
Пока для меня всё равно выглядит очень странной фичёй
AV
ну и да, думаю оно там торчит просто чисто исторически
AV
в том же Go вначале тоже консерва была
AV
потом выпилили
AV
и впилили точный GC