Сообщение Re[4]: Подавить warning в древнем GCC от 25.01.2024 14:23
Изменено 25.01.2024 15:16 wander
Re[4]: Подавить warning в древнем GCC
Здравствуйте, fk0, Вы писали:
fk0> А вот с этого момента поподробнее. Кто его вынуждает быть inline и каким способом???
fk0>В C++ такого не предусмотрено, чтоб кого-то вынуждать.
В C++ нет интерфейсов. Интерфейсы в C++ — это классы с чистовиртуальными функциями.
Но деструктор отличается от остальных функций тем, что у него, даже если он чистовиртуальный, должна быть реализация.
Если нужен виртуальный деструктор в интерфейсном хедере, то есть два пути:
1) либо мы предоставляем реализацию деструктора в inline прямо в хедере,
2) либо обязать тех, кто реализует интерфейс, создавать эту реализацию в своей какой-то единице трансляции, но это неудобно.
Скажем так, из соображений удобства использования, деструктор, если он виртуальный, вынужден быть inline.
А выход простой из этого. Виртуальные деструкторы вообще не нужны. Мы все равно благодаря Release не удаляем через явный delete ничего.
А Release сама по себе виртуальная достаточно, чтобы знать фактический тип наследника и правильно его уничтожить.
fk0> В каком смысле "там же"? И чем обычный деструктор кардинально отличается от спец. функции?
fk0>Мне кажется с точки зрения компилятора -- ни чем. В конечном счёте функция как функция. Когда
fk0>уже до машинного кода дошло.
В том же модуле, с использованием того же аллокатора и т.д. Удалять в одном модуле через delete объект, который создал другой модуль (возможно на другом языке) — это неправильно.
А вот виртуальная функция Release, которая имплементирована в другом модуле — другое дело. При этом ее вызов никак не привязан к внутреннему
ABI модуля (в отличие от вызова delete, которому нужно ABI конкретной реализации C++).
fk0> Но я никак не понимаю, что за паттерн.
А я не пойму к чему эти вопросы?
Хочешь ревью этой системы провести? Или что?
fk0> А вот с этого момента поподробнее. Кто его вынуждает быть inline и каким способом???
fk0>В C++ такого не предусмотрено, чтоб кого-то вынуждать.
В C++ нет интерфейсов. Интерфейсы в C++ — это классы с чистовиртуальными функциями.
Но деструктор отличается от остальных функций тем, что у него, даже если он чистовиртуальный, должна быть реализация.
Если нужен виртуальный деструктор в интерфейсном хедере, то есть два пути:
1) либо мы предоставляем реализацию деструктора в inline прямо в хедере,
2) либо обязать тех, кто реализует интерфейс, создавать эту реализацию в своей какой-то единице трансляции, но это неудобно.
Скажем так, из соображений удобства использования, деструктор, если он виртуальный, вынужден быть inline.
А выход простой из этого. Виртуальные деструкторы вообще не нужны. Мы все равно благодаря Release не удаляем через явный delete ничего.
А Release сама по себе виртуальная достаточно, чтобы знать фактический тип наследника и правильно его уничтожить.
fk0> В каком смысле "там же"? И чем обычный деструктор кардинально отличается от спец. функции?
fk0>Мне кажется с точки зрения компилятора -- ни чем. В конечном счёте функция как функция. Когда
fk0>уже до машинного кода дошло.
В том же модуле, с использованием того же аллокатора и т.д. Удалять в одном модуле через delete объект, который создал другой модуль (возможно на другом языке) — это неправильно.
А вот виртуальная функция Release, которая имплементирована в другом модуле — другое дело. При этом ее вызов никак не привязан к внутреннему
ABI модуля (в отличие от вызова delete, которому нужно ABI конкретной реализации C++).
fk0> Но я никак не понимаю, что за паттерн.
А я не пойму к чему эти вопросы?
Хочешь ревью этой системы провести? Или что?
Re[4]: Подавить warning в древнем GCC
Здравствуйте, fk0, Вы писали:
fk0> А вот с этого момента поподробнее. Кто его вынуждает быть inline и каким способом???
fk0>В C++ такого не предусмотрено, чтоб кого-то вынуждать.
В C++ нет интерфейсов. Интерфейсы в C++ — это классы с чистовиртуальными функциями.
Но деструктор отличается от остальных функций тем, что у него, даже если он чистовиртуальный, должна быть реализация.
Если нужен виртуальный деструктор в интерфейсном хедере, то есть два пути:
1) либо мы предоставляем реализацию деструктора в inline прямо в хедере,
2) либо обязать тех, кто реализует интерфейс, создавать эту реализацию в своей какой-то единице трансляции, но это неудобно.
Скажем так, из соображений удобства использования, деструктор, если он виртуальный, вынужден быть inline.
А выход простой из этого. Виртуальные деструкторы вообще не нужны. Мы все равно благодаря Release не удаляем через явный delete ничего.
А Release сама по себе виртуальная достаточно, чтобы знать фактический тип наследника и правильно его уничтожить.
fk0> В каком смысле "там же"? И чем обычный деструктор кардинально отличается от спец. функции?
fk0>Мне кажется с точки зрения компилятора -- ни чем. В конечном счёте функция как функция. Когда
fk0>уже до машинного кода дошло.
В том же модуле, с использованием того же аллокатора и т.д. Удалять в одном модуле через delete объект, который создал другой модуль (возможно на другом языке) — это неправильно.
А вот виртуальная функция Release, которая имплементирована в другом модуле — другое дело. При этом ее вызов никак не привязан к внутреннему
ABI модуля (в отличие от вызова delete, которому нужно ABI конкретной реализации C++).
_____
UPD. Добавлю, что если мы делаем "заголовочный файл" интерфейса для другого языка (отличного от C++), то деструктор там выглядит чужеродно.
А коль скоро он не нужен для работы, то и писать его и прокидывать в слои совместимости с другими языками, не нужно.
Ну вот посмотри на интерфейсы COM. Там тоже нет виртуальных деструкторов. Мотивация точно такая же.
fk0> Но я никак не понимаю, что за паттерн.
А я не пойму к чему эти вопросы?
Хочешь ревью этой системы провести? Или что?
fk0> А вот с этого момента поподробнее. Кто его вынуждает быть inline и каким способом???
fk0>В C++ такого не предусмотрено, чтоб кого-то вынуждать.
В C++ нет интерфейсов. Интерфейсы в C++ — это классы с чистовиртуальными функциями.
Но деструктор отличается от остальных функций тем, что у него, даже если он чистовиртуальный, должна быть реализация.
Если нужен виртуальный деструктор в интерфейсном хедере, то есть два пути:
1) либо мы предоставляем реализацию деструктора в inline прямо в хедере,
2) либо обязать тех, кто реализует интерфейс, создавать эту реализацию в своей какой-то единице трансляции, но это неудобно.
Скажем так, из соображений удобства использования, деструктор, если он виртуальный, вынужден быть inline.
А выход простой из этого. Виртуальные деструкторы вообще не нужны. Мы все равно благодаря Release не удаляем через явный delete ничего.
А Release сама по себе виртуальная достаточно, чтобы знать фактический тип наследника и правильно его уничтожить.
fk0> В каком смысле "там же"? И чем обычный деструктор кардинально отличается от спец. функции?
fk0>Мне кажется с точки зрения компилятора -- ни чем. В конечном счёте функция как функция. Когда
fk0>уже до машинного кода дошло.
В том же модуле, с использованием того же аллокатора и т.д. Удалять в одном модуле через delete объект, который создал другой модуль (возможно на другом языке) — это неправильно.
А вот виртуальная функция Release, которая имплементирована в другом модуле — другое дело. При этом ее вызов никак не привязан к внутреннему
ABI модуля (в отличие от вызова delete, которому нужно ABI конкретной реализации C++).
_____
UPD. Добавлю, что если мы делаем "заголовочный файл" интерфейса для другого языка (отличного от C++), то деструктор там выглядит чужеродно.
А коль скоро он не нужен для работы, то и писать его и прокидывать в слои совместимости с другими языками, не нужно.
Ну вот посмотри на интерфейсы COM. Там тоже нет виртуальных деструкторов. Мотивация точно такая же.
fk0> Но я никак не понимаю, что за паттерн.
А я не пойму к чему эти вопросы?
Хочешь ревью этой системы провести? Или что?