линкер скрипты и кастомный компилятор) нельзя такие функции покрывать тестами -- они специально спрятаны

как ты к этой функции из другого TU обратишься?

что такое TU? translation unit?

да

да в коде продукта - никак, мне бы только для тестов её дёрнуть

теоретически можно #include "myfile.cpp", но не факт что это будет работать для твоего случая

спасибо, помогло

Дак выпили из анонимного неймспейса

- Доктор, у меня, если надавить вот здесь, болит.
- А если не надавливать, не болит?
- Нет.
- Ну так и не надавливайте. С вас 1000 рублей.

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

Зачем ты вообще метод в details тестами покрываешь? Чтобы при любом изменении их выполнить?

Объект, композиция объектов, конструируется так, что каждый следующий данное-член зависит от предыдущего (используется при инициализации). При вызове деструктора в деструкторах данных-членов происходит освобождение ресурсов, которыми они владеют. Это происходит в порядке обратном порядку инициализации. Что корректно. Но если я вызываю оператор присваивания (автогенерированный), то он разрушает данные-члены в прямом порядке, что некорректно. Как этого избежать?

Вообще в языке/библиотеке зависит что-то от порядка присваивания данных-членов для композитных типов данных?

Оператор присваивания не разрушает, вот и ответ.

можно поразвёрнутее, не делая умный вид?

Не хотел делать умный вид) Хотя конечно если бы он разрушал конфликт очевидно есть.

operator = по умолчанию вызывает operator = для всех баз и полей, и так далее. Идеологически operator = и уничтожить-и-создать-поверх развязанные операции.

ладно. Там каждое данное-член, допустим, это std::unique_ptr над ресурсом

так что ресурс разрушается

и оператор пусть будет move-assignment operator-ом