>> Ну, и? Перегружать operator=? Как из оператора = вызвать деструктор для self^W this?
> В С++ не надо вызывать деструкторы руками, RAII для этого и придуман.
> Компилятор сгенерит код, который вызовет деструкторы где и когда нужно в
> нужном порядке. Если у тебя есть выделение памяти в хипе для
> дейта-мемберов используй смарт-поинтеры с их конструкторами, деструкторами и присваиваниями,
> которые тоже будут вызваны автоматически. Твой std::string это и есть пример
> - его деструктор будет вызван во время вызова деструктора объекта а,
> но до исполнения кода самого деструктора объекта a.Тут ты меня потерял. "Во время вызова деструктора" но "до исполнения деструктора"? В смысле имеется в виду, что деструктор -- это что-то большее, чем мой код деструктора. Это что-то большее может быть побито на куски и эти куски могут быть перетасованы с кодом, где я жонглирую объектами? Или имеется в виду, что есть идеологически правильное место для вызова деструктора, которое в силу copy_elision не используется, ... и хрен его знает.
Или ладно, иначе задам вопрос. То есть в этом примере деструктор для string вызывается, вся память из под обоих string'ов корректно освобождается, и всё ок? То есть, допустим, если у меня в этом Test'е будет лежать грядка uniq_ptr указателей, то их деструкторы будут вызваны, до того, как они будут перезаписаны присваиванием, и вся память будет корректно освобождена, так?
А! Ну тут фишка в том, что по дефолту копирование полей Test выполняется тем же operator=, но в тех реализациях которые на типы полей навешаны. А поскольку на стринг повешена реализация, которая умеет эту ситуацию корректно разруливать, то всё проходит без эксцессов. Ну да, если так, то понятно.
> Если ты используешь
> нетривиальное присваивание, то переопределяй оператор присваивания и руками управляй
> выделениями и освобождениями памяти для мемберов объекта.
Ок.
> Такое нужно раз в сто лет.
Постоянно же. Ты создал File объект, он содержит файловый дескриптор. Ты открыл другой файл, положил новый File в ту же переменную и вот тебе уже это нужно. Или, скажем, я столкнулся с тем, что у меня есть объект, лежащий членом-переменной в другом объекте. Я всегда хочу всегда иметь его инициализированным, но иногда менять на другой инициализированный объект. И эмм... это не очень работает, потому что деинициализация не триггерится вовремя. А когда триггерится, уже поздно пить боржоми. Даже хуже, мне кажется таким образом можно сначала дать утечь памяти, а потом на другой кусок сделать free дважды.
Это очень удобная штука, на самом деле. Я не очень понимаю, как вообще RAII может работать без неё. Подозреваю, что просто надо вспомнить детство, ассемблер, и начать снова думать не о значениях и переменных, а о кусках памяти, которые эти значения занимают, и указателях на эти куски памяти.
> С++ смарт-поинтеры это примеры "владеющих" обёрток над голыми указателями
> и хандлерами ОС.
Да, во. Хороший пример. Я и говорю, что это постоянно нужно. Но смартпоинтеры ж обёртки над указателями, а мне бы то же самое, но над неуказателем. А, ну такую штуку можно написать, наверное, единожды в виде параметризованного типа, и потом заворачивать объекты в этот тип. Можно, наверное, даже взять код uniq_ptr, выкинуть оттуда delete и *, если они там есть, и переименовать в uniq_value.
