АР
вот и отлаживай, называется...
Size: a a a
2020 December 17
IZ
я думаю, там, где нет чистого Си, нет и нарушений ODR (или они нереально редки)
Это не так. ODR индифирентно к флейвору языка
IZ
Самый расхожый вариант ODR на практике -- это несколько экземпляров CRT в программе, в виде статики и .dll например, или в виде .dll разных конфигураций.
Причём, очень часто ЭТО РАБОТАЕТ БЕЗ ПРОБЛЕМ (до поры , до времени)
Причём, очень часто ЭТО РАБОТАЕТ БЕЗ ПРОБЛЕМ (до поры , до времени)
IZ
как явление - да, но частота возникновения вызванных ODR багов, я думаю, в С++ пониже
Не думаю. В С++ больше ODR, так что чисто по вероятности -- она выше.
ПК
я думаю, там, где нет чистого Си, нет и нарушений ODR (или они нереально редки)
На изи можно получать ODR violation в шаблонах и в inline
A
Самый расхожый вариант ODR на практике -- это несколько экземпляров CRT в программе, в виде статики и .dll например, или в виде .dll разных конфигураций.
Причём, очень часто ЭТО РАБОТАЕТ БЕЗ ПРОБЛЕМ (до поры , до времени)
Причём, очень часто ЭТО РАБОТАЕТ БЕЗ ПРОБЛЕМ (до поры , до времени)
Такая проблема была один раз, но не с CRT, а с нашей собственной библиотекой, которую юзают почти все, поэтому она инстанциировалась где попало и как попало (в dll, в .ехе), пока не навели порядок. Но я не уверен, что этот класс проблем подпадает под вопрос.
A
На изи можно получать ODR violation в шаблонах и в inline
Если одинаково называть разные классы или свободные функции?
ПК
Если одинаково называть разные классы или свободные функции?
С inline можно например дефайны юзать внутри и в разных TU получать разные тела из-за этого
ПК
С шаблонами можно получить ODR violation в связке с полными/неполными типами
FZ
Как вы боретесь с багами в ваших проектах, возникшими из-за нарушения ODR?
Анонимный опрос
0%
Не борюсь никак, код работает и так
0%
С ними борится наш лид и я не знаю, как
0%
Я борюсь с ними с помощью статических анализаторов кода
0%
Я борюсь с ними с помощью размышлений и терзаний
юнити сборки заряжаем время от времени, вроде находили несколько. модуль в один cpp файл
IZ
Такая проблема была один раз, но не с CRT, а с нашей собственной библиотекой, которую юзают почти все, поэтому она инстанциировалась где попало и как попало (в dll, в .ехе), пока не навели порядок. Но я не уверен, что этот класс проблем подпадает под вопрос.
Подпадает 100%
IZ
это не ODR violation, это множественное инстанциирование статических объектов внутри библиотеки по всем правимлам С++
Это и есть ODR
ПК
Связь прямая: свободная функция не в namespace, не static и не inline - большой красный флаг
Это если две разные либы и у каждой свой namespace, да, шанс уменьшается. А если есть две одинаковые либы, но разной версии, то тут уже могут быть проблемы (хотя всё собирается)
ПК
это не ODR violation, это множественное инстанциирование статических объектов внутри библиотеки по всем правимлам С++
Ты о чём?
II
юнити сборки заряжаем время от времени, вроде находили несколько. модуль в один cpp файл
это чтобы при юнити сам компилер выругался на повторные определения?