Вывод высосан из пальца, аргументов нет. NVI, brige — это все хорошо, но только не надо забывать что деструктор — это чисто техническая вещь, к обязанностям интерфейса класса он как правило не имеет ни малейшего отношения.
> приблизить друг другу операции создания и удаления и таким образом сделать код более простым, стройным.
Да что вы говорите. Каким образом код станет проще и стройнее? Создание и удаление в современном C++ — это RAII, new и delete действительно рядом написаны в коде, но вот только в большом количестве случаев — удаление полиморфное: shared_ptr(new Service); при этом создание и удаление производится как правило в разных контекстах
> Например, такие объекты нельзя использовать в объединениях.
Еще есть ограничения, кроме непереносимого юниона? дальше вроде о переносе на другие платформы упоминается.
Итого: стоящих аргументов не видно, примеров плохого кода с полиморфным удалением нет.
никогда не вылезали за 2Gb в 32-битном процессе? бывают такие задачи.
Давайте, расскажите мне как использовать auto_ptr на интерфейс без полиморфного удаления
> Вывод: полиморфное удаление — подозрительная штука.
Вывод высосан из пальца, аргументов нет. NVI, brige — это все хорошо, но только не надо забывать что деструктор — это чисто техническая вещь, к обязанностям интерфейса класса он как правило не имеет ни малейшего отношения.
> приблизить друг другу операции создания и удаления и таким образом сделать код более простым, стройным.
Да что вы говорите. Каким образом код станет проще и стройнее? Создание и удаление в современном C++ — это RAII, new и delete действительно рядом написаны в коде, но вот только в большом количестве случаев — удаление полиморфное: shared_ptr(new Service); при этом создание и удаление производится как правило в разных контекстах
> Например, такие объекты нельзя использовать в объединениях.
Еще есть ограничения, кроме непереносимого юниона? дальше вроде о переносе на другие платформы упоминается.
Итого: стоящих аргументов не видно, примеров плохого кода с полиморфным удалением нет.