Здравствуйте, Евгений Музыченко, Вы писали:
A>>Тем не менее, я сильно подозреваю, что в деструкторах там какой-нибудь ::WaitForMultipleObjects() перед освобождением ресурсов
ЕМ>То есть, проблема не в освобождении, как таковом, а в том, что оно выполняется неимоверно криво, и самый простой способ с этим справиться — замести под ковер.
Во-первых, это всего лишь моё предположение.
Во-вторых, если оно соответствует действительности, не факт, что можно переписать лучше. Не уронив перфоманс загрузки, скажем.
В-третьих, дело в освобождении как таковом, потому, что это код, который ничего не делает. Про это я и написал, а ниже ещё раз поясню.
A>>сказал, что мы пришли к очень криповой ситуации. Десктопный софт при бесполезном закрытии тратит время на бесполезные деструкторы, что снижает отзывчивость, хотя и ОС, и программы всё умеют делать быстро и безопасно. Техлиды Майкрософт умеют смотреть правде в глаза.
ЕМ>Нет, они умеют назначать виновных. Умей они смотреть правде в глаза — перечислили бы навскидку с десяток куда более очевидных проблем, приводящих к тормозам везде и всюду. Но те проблемы трогать опасно — не дай бог выяснится, что тормозит как раз из-за перехода на технологию, которая несколько лет назад продвигалась в качестве передовой. А деструкторы были передовой технологией только в 70-80-х, с тех пор там не было никаких прорывов, так что можно наглядно продемонстрировать снижение тормозов за счет избавления от заведомо кривых деструкторов, но акцент сделать не на кривизне, а на якобы бесполезности деструкторов, как таковых.
Такие вещи надо обсуждать поимённо, чтобы не скатиться во флейм. И, вероятно, не в WinAPI. Про какие технологии речь? CLR?
A>>если у меня замкнёт мою светодиодную ленту с левым БП и выключится компьютер, а программа и ОС это не отработают гарантированно стабильно, то зачем такие программа и ОС.
ЕМ>Не понял. Каким образом они могут "отработать" на выключенном компьютере? Это к чему вообще было?
Разумеется, речь про то, что после аварийного выключения (когда деструкторам не дали отработать!), правильно написанная программа и ОС будут работать при следующем запуске, как будто ничего не случилось. Они и работают. Даже данные не теряют, кроме тех, которые by design требуют явного сохранения в виде подтверждения пользователем, да и те почти всегда можно восстановить (если авторам было не лень заморочиться, как Word делает, например).
Вот это и есть главный point, почему деструкторы *при выходе* бесполезны. Что я потеряю, если они не вызовутся? И если потеряю, почему нельзя написать так же, как Стим и Windows 7, которые я годами вырубал по-хардкору и ни разу не потерял ничего?
A>>Я думаю, у них деградация со временем, как и везде. На смену смелым людям, запилившим классную фичу, пришли новички, которые увидели, что всё работает не так, как их учили и привели код в соответствие со своими шаблонными извилинами.
ЕМ>О том и речь, что большинство новичков, неплохо разбираясь в парадигмах, шаблонах и паттернах, лишь отдаленно представляет себе, как это все работает "под капотом". В итоге получается классика.
Раз мы анекдоты рассказываем. Был у меня коллега, с которым мы писали одну библиотеку. Я ему предложил смелый маркетинговый ход: поместить её в системный неймспейс, технических проблем с этим не было. Что бы мы имели. Во-первых, бесплатный хайп, на форумах стоял бы треск жоп, мол, "Что эти н... себе позволяют?!". Во-вторых, выделились бы из рядов конкурентов. В-третьих, программисты любят, когда у них только системный неймспейс, и не любят вызывать код из VasyaPupkine, как по гайдлайнам полагается. Коллега начал возражать, что в один день мы можем поиметь проблем с конфликтами имён (если вдруг стандартизируют весьма специфичный функционал, названный соответственно, ага). Стало ясно, жопа у кого-то уже треснула Вывод таков, что как ни печально, в нашей профессии роль ритуалов, табу и прочей херни высока, как мало где ещё.
Вот, вопрос выше ("Что я потеряю, если они не вызовутся?"), если кто-то не согласен.
Здравствуйте, Alekzander, Вы писали:
A>В-третьих, дело в освобождении как таковом, потому, что это код, который ничего не делает.
Код, как минимум, должен проверять, что все в порядке, а не тупо херить все напрочь. Иначе, если что-то где-то портится, можно годами безуспешно искать ошибки наугад.
A>Про какие технологии речь? CLR?
Так я не в курсе, о чем именно говорили парни из MS. Но, коли они тоже подняли этот вопрос, там тоже сумели довести до абсурда.
A>речь про то, что после аварийного выключения (когда деструкторам не дали отработать!), правильно написанная программа и ОС будут работать при следующем запуске, как будто ничего не случилось.
Если они будут работать "как будто ничего не случилось", то вскоре непременно что-нибудь случится. В таких случаях они, как известно, стараются восстановить последнее известное состояние. А это не бесплатно — в файловой системе приходится оформлять многие операции транзакциями, в обычных приложениях — создавать лишние копии файлов. Делать это постоянно, месяцами-годами, только для того, чтобы в редких случаях оправдать аварийные отключения — так себе эффективность. Если бы все случаи аварийного завершения исчерпывались только отключением питания, проще было бы везде ставить резервные батареи.
A>Вот это и есть главный point, почему деструкторы *при выходе* бесполезны. Что я потеряю, если они не вызовутся?
Те ресурсы, которые затрачиваются на обеспечение целостности.
A>почему нельзя написать так же, как Стим и Windows 7, которые я годами вырубал по-хардкору и ни разу не потерял ничего?
Написать можно, только зачем возводить это в систему? Я вот ни разу не хочу добавлять в свой софт специальные меры на тот случай, если пользователю покажется удобнее отключать компьютер без резервного питания выдергиванием шнура из розетки.
Отдельные пользователи регулярно бухтят, что они хотели бы запустить звуковой поток с устройства USB или на него, а потом тупо выдергивать устройство из компьютера, и через некоторое время вставлять обратно, и не париться с перезапуском потока. Чисто технически я мог бы это сделать, но на кой? Чтобы ленивые смогли стать еще ленивее? А что дальше? Устройство для автоматического вываливания члена из штанов при расслаблении сфинктера, и втягивания обратно после завершения процесса?
Здравствуйте, Евгений Музыченко, Вы писали:
A>>В-третьих, дело в освобождении как таковом, потому, что это код, который ничего не делает.
ЕМ>Код, как минимум, должен проверять, что все в порядке, а не тупо херить все напрочь. Иначе, если что-то где-то портится, можно годами безуспешно искать ошибки наугад.
При освобождении проверять? Кто так вообще делает и для чего? Код должен логгировать результаты всех вызовов по мере надобности, и этого достаточно, чтобы полностью восстановить последовательность событий, приведшую к проблемам.
A>>речь про то, что после аварийного выключения (когда деструкторам не дали отработать!), правильно написанная программа и ОС будут работать при следующем запуске, как будто ничего не случилось.
ЕМ>Если они будут работать "как будто ничего не случилось", то вскоре непременно что-нибудь случится. В таких случаях они, как известно, стараются восстановить последнее известное состояние. А это не бесплатно — в файловой системе приходится оформлять многие операции транзакциями, в обычных приложениях — создавать лишние копии файлов. Делать это постоянно, месяцами-годами, только для того, чтобы в редких случаях оправдать аварийные отключения — так себе эффективность. Если бы все случаи аварийного завершения исчерпывались только отключением питания, проще было бы везде ставить резервные батареи.
Мы эту цену УЖЕ платим, поскольку все программы и все ОС должны работать (и работают!) с учётом возможного внезапного отключения.
A>>Вот это и есть главный point, почему деструкторы *при выходе* бесполезны. Что я потеряю, если они не вызовутся?
ЕМ>Те ресурсы, которые затрачиваются на обеспечение целостности.
Я, как пользователь, когда вырубаю программу в PE, теряю "ресурсы, которые затрачиваются на обеспечение целостности"? И чтобы их не потерять, надо выходить через WM_CLOSE?
Или же, всё-таки, эти ресурсы *в любом случае* направлены на фактор, над которым никто не властен — исчезновение питания — и теперь выбор стоит: или получать за эту цену оплаченные услуги в виде возможности закрывать быстро, или ничего не получать, заплатить просто так?
A>>почему нельзя написать так же, как Стим и Windows 7, которые я годами вырубал по-хардкору и ни разу не потерял ничего?
ЕМ>Написать можно, только зачем возводить это в систему? Я вот ни разу не хочу добавлять в свой софт специальные меры на тот случай, если пользователю покажется удобнее отключать компьютер без резервного питания выдергиванием шнура из розетки.
О каких мерах идёт речь? Достаточно в 95% случаев всего-навсего сериализовать всё сразу из разных OnOK(), а не накапливать изменения до OnExit(). Программисту это ничего не стоит, за таким решением может стоять только принципиальное нежелание.
ЕМ>Отдельные пользователи регулярно бухтят, что они хотели бы запустить звуковой поток с устройства USB или на него, а потом тупо выдергивать устройство из компьютера, и через некоторое время вставлять обратно, и не париться с перезапуском потока. Чисто технически я мог бы это сделать, но на кой? Чтобы ленивые смогли стать еще ленивее? А что дальше? Устройство для автоматического вываливания члена из штанов при расслаблении сфинктера, и втягивания обратно после завершения процесса?
Насколько я помню, у тебя успешный бизнес, и кто я такой, чтобы учить тебя отношениям с клиентами. По крайней мере, бесплатно
Здравствуйте, Alekzander, Вы писали:
A>При освобождении проверять?
В том числе.
A>Кто так вообще делает и для чего?
Кто заинтересован быстрее вылавливать ошибки, тот и делает. Как минимум — в отладочных версиях кода. В релизных это можно и опустить.
A>Код должен логгировать результаты всех вызовов по мере надобности, и этого достаточно, чтобы полностью восстановить последовательность событий, приведшую к проблемам.
И что Вы будете "логгировать", чтобы найти, где может портиться участок памяти объекта? А еще при освобождении памяти можно заполнять блок такими значениями, которые с высокой вероятностью вызовут срабатывание проверок при возможном ошибочном обращении. Это тоже обычно делается только в отладочных сборках, но освобождение всей кучи через HeapDestroy этого не сделает, и не факт, что переведет все страницы кучи в недоступное состояние. За этим тоже нужно как-то проследить.
A>все программы и все ОС должны работать (и работают!) с учётом возможного внезапного отключения.
С каких пор все программы обязаны так работать? Типовая программа вообще не обязана предпринимать какие-то особые усилия, это задача ОС и оборудования. Специальные меры имеет смысл принимать лишь в "особо важных" программах, да и то средства для этого, как правило, тоже предоставляет ОС.
A>когда вырубаю программу в PE
Что это означает? Аварийно завершаете при помощи Process Explorer?
A>теряю "ресурсы, которые затрачиваются на обеспечение целостности"? И чтобы их не потерять, надо выходить через WM_CLOSE?
Если программа не принимает специальных мер на случай аварийного завершения — ничего не теряете, кроме несохраненных данных. Если принимает, то возникает вопрос — зачем она это делает?
A>эти ресурсы *в любом случае* направлены на фактор, над которым никто не властен — исчезновение питания
Почему не властен? Не знаю, как Вы, а я вот властен или работать на ноутбуке, или подключить к десктопу бесперебойник. Но это не гарантирует от аварийного завершения на уровне ядра, поэтому на NTFS работать выгоднее, чем на FAT, несмотря на издержки. Эти издержки вполне разумны — транзакциями оформляются только операции, критичные для ФС, так что основная масса операций не сопровождается ростом расходов. Если я набираю длинный текст в редакторе, мне выгодно автоматическое сохранение, а если прокручиваю длинный текст в браузере, то мне по барабану, сохранит он позицию при аварийном завершении, или нет. Но он за каким-то хреном стремится сохранять и позицию, и еще кучу текущих режимов, и совершенно не спрашивает меня об этом, а надо бы — ресурсы-то мои, а не его.
A>получать за эту цену оплаченные услуги в виде возможности закрывать быстро
Если "быстро" — это секунды вместо минут, то еще худо-бедно тянет на "оплаченные услуги". Если же это доли секунды вместо двух-трех секунд, то сколько раз в час нужно это проделывать, чтобы вообще возникла сама идея считать это благом?
A>>>почему нельзя написать так же, как Стим и Windows 7, которые я годами вырубал по-хардкору и ни разу не потерял ничего?
ЕМ>>Написать можно, только зачем возводить это в систему? Я вот ни разу не хочу добавлять в свой софт специальные меры на тот случай, если пользователю покажется удобнее отключать компьютер без резервного питания выдергиванием шнура из розетки.
A>Достаточно в 95% случаев всего-навсего сериализовать всё сразу из разных OnOK(), а не накапливать изменения до OnExit().
Когда в тех OnOK() делается что-то мелкое — не вопрос, а если в каждом OnOK() делается только часть подготовки к некой крупной операции, обрабатывающей большие объемы данных, запускающей сложные процессы и т.п.?
Здравствуйте, Евгений Музыченко, Вы писали:
A>>Код должен логгировать результаты всех вызовов по мере надобности, и этого достаточно, чтобы полностью восстановить последовательность событий, приведшую к проблемам.
ЕМ>И что Вы будете "логгировать", чтобы найти, где может портиться участок памяти объекта? А еще при освобождении памяти можно заполнять блок такими значениями, которые с высокой вероятностью вызовут срабатывание проверок при возможном ошибочном обращении. Это тоже обычно делается только в отладочных сборках, но освобождение всей кучи через HeapDestroy этого не сделает, и не факт, что переведет все страницы кучи в недоступное состояние. За этим тоже нужно как-то проследить.
Это первый попавшийся код из первого попавшегося проекта, то есть, вот этими вот вызовами LOGERROR усеяно буквально всё. Теперь хотелось бы увидеть, о чём говоришь ты. Где и как ты проверяешь в деструкторах, "где может портиться участок памяти объекта"? У большинства, насколько я в курсе, максимум, дебажная версия new/delete используется.
Это мне просто интересно. А ключевой-то вопрос, как наличие штатного "аварийного" выхода мешает писать деструкторы. Кому надо — тот пусть выходит через WM_CLOSE со всем логгированием и чем там ещё. А кому надо — через быстрый выход.
какой-то студент пишет, что программировать так, чтобы исключить ошибки — это максимализм. На то он и студент. Человек с десятилетиями опыта понимает, что ошибки лучше исключать при помощи специальных практик. Заменять подусловия is_in_set'ом, использовать Йода-сравнения, и т.п. Поэтому, буквальный ответ на вопрос, что я буду делать, если исключить ошибку не удалось и "портится участок памяти объекта" — плакать буду. Среди этих ошибок бывают такие (наведённые), что их ничем не возьмёшь, только наитием свыше. Там дебаггер-то не помогает, не то, что логгер.
A>>все программы и все ОС должны работать (и работают!) с учётом возможного внезапного отключения.
ЕМ>С каких пор все программы обязаны так работать? Типовая программа вообще не обязана предпринимать какие-то особые усилия, это задача ОС и оборудования. Специальные меры имеет смысл принимать лишь в "особо важных" программах, да и то средства для этого, как правило, тоже предоставляет ОС.
Назови виндовую программу, которая не переживёт аппаратный ресет. У которой после этого возникнут проблемы.
A>>когда вырубаю программу в PE
ЕМ>Что это означает? Аварийно завершаете при помощи Process Explorer?
Да.
ЕМ>Если "быстро" — это секунды вместо минут, то еще худо-бедно тянет на "оплаченные услуги". Если же это доли секунды вместо двух-трех секунд, то сколько раз в час нужно это проделывать, чтобы вообще возникла сама идея считать это благом?
Это называется "отзывчивость UI". Люди, видишь, не машины, они секунды не складывают и доли не считают. Самая малая задержка вызывает сильный дискомфорт. Попробуй в ключевой OnButtonClick() добавить ::Sleep(2500); и засекай, через сколько юзеры начнут писать письма.
Когда старый смартфон ИЗРЕДКА начинает откликаться на нажатия на полсекунды позднее, его выбрасывают.
Это реалии сегодняшнего дня, извини. Даже если кажется, что это избалованность. Как мне говорил один товарищ: я буду переплачивать за айфон сотни долларов, потому, что он всегда мгновенно откликается, а Андроид — не всегда. А потмо он же жаловался, что в новых Айфонах это сломали и он теперь ничем от Андроида не отличается. Так это или нет, я не в курсе, но это типичная юзерская потребность. Как юайщик ответственно заявляю.
A>>>>почему нельзя написать так же, как Стим и Windows 7, которые я годами вырубал по-хардкору и ни разу не потерял ничего?
ЕМ>>>Написать можно, только зачем возводить это в систему? Я вот ни разу не хочу добавлять в свой софт специальные меры на тот случай, если пользователю покажется удобнее отключать компьютер без резервного питания выдергиванием шнура из розетки.
A>>Достаточно в 95% случаев всего-навсего сериализовать всё сразу из разных OnOK(), а не накапливать изменения до OnExit().
ЕМ>Когда в тех OnOK() делается что-то мелкое — не вопрос, а если в каждом OnOK() делается только часть подготовки к некой крупной операции, обрабатывающей большие объемы данных, запускающей сложные процессы и т.п.?
Мне кажется, это как раз оставшиеся 5%. Понятно, что не всегда так можно, но стремиться к этому надо.
Здравствуйте, Alekzander, Вы писали:
A>Пришла пора перейти от слов к коду
Зачем? Что в этом коде есть такого, что нельзя описать тем же или меньшим количеством символов?
A>Это первый попавшийся код из первого попавшегося проекта, то есть, вот этими вот вызовами LOGERROR усеяно буквально всё.
Это самый убогий вид протоколирования, когда регистрируются исключительно ошибки. Все, что можно увидеть в таком логе — это информацию о внезапно возникшей ошибке. А предыстории, которая к этой ошибке привела, там нет.
Самое смешное, что многие именно это и называют "протоколированием" или "логированием". И искренне удивляются, что можно (а главное — зачем) делать что-то еще.
Вот пример подобного искреннего удивления от разработчиков весьма навороченного дизассемблера/декомпилятора Ghidra. У них там не просто пишутся строчки в файл, а вызываются "логгеры", которые специально создаются и настраиваются. Все это великолепие даже на максимальных уровнях подробности порождает убогий протокол из нескольких десятков строк, от которого толку ровно ноль. Еще в топике есть показательный комментарий "ну чего ж вы хотели от опенсорса". Слава богу, не весь опенсорс такой.
A>хотелось бы увидеть, о чём говоришь ты. Где и как ты проверяешь в деструкторах, "где может портиться участок памяти объекта"?
Целостность объектов я проверяю не только в деструкторах, а практически в каждом методе каждого объекта, если только не нужно обеспечить предельно быстрое выполнение. И логи у меня генерятся порой по нескольку мегабайт в секунду. А в деструкторах я обычно проверяю, что все важные операции (вроде остановки звукового потока, его отвязки от клиентов и т.п.) были выполнены верхними уровнями логики, и деструктору осталось лишь уничтожить сугубо локальные объекты и освободить память.
A>У большинства, насколько я в курсе, максимум, дебажная версия new/delete используется.
Ну и флаг им в руки. Для сравнительно простого (однопоточного, без асинхронных событий, с небольшим количеством состояний и т.п.) кода этого вполне достаточно.
A>как наличие штатного "аварийного" выхода
Штатный "аварийный" выход — это что-то вроде планового катапультирования для пилота?
A>мешает писать деструкторы.
Писать — не мешает. Мешает деструкторам реализовать возможность контроля целостности своих объектов, в том числе взаимного.
A>Кому надо — тот пусть выходит через WM_CLOSE со всем логгированием и чем там ещё. А кому надо — через быстрый выход.
А кто может — делает выход через WM_CLOSE, со всем логированием, и внезапно тоже быстрый.
A>ошибки лучше исключать при помощи специальных практик.
А регулярный контроль, в том числе в деструкторах — одна из таких практик.
A>использовать Йода-сравнения
В них был какой-то смысл лет сорок назад. С тех пор, как компиляторы научились предупреждать о подозрительных конструкциях, он почти пропал.
A>Среди этих ошибок бывают такие (наведённые), что их ничем не возьмёшь, только наитием свыше. Там дебаггер-то не помогает, не то, что логгер.
Самое смешное в том, что при наведенных ошибках хороший логгер помогает куда лучше самого крутого отладчика.
A>Назови виндовую программу, которая не переживёт аппаратный ресет. У которой после этого возникнут проблемы.
Программы-то все переживут, кроме самомодифицирующихся, коих мало. И проблем у большинства программ тоже не возникнет — они просто скажут "file is corrupt". Проблема возникнет у того, кому этот file сколько-нибудь дорог. Большинство программ не из разряда "профессиональных" не принимает никаких мер к защите данных. А если сброс или ошибка ядра произойдет в момент перестройки какой-нибудь из системных БД, может потребоваться чинить систему. Если хочется попробовать — понажимайте тот ресет во время установки обновлений, опознания новых устройств, удаления программ и т.п.
ЕМ>>Аварийно завершаете при помощи Process Explorer?
A>Да.
Если не секрет, зачем делать это с независшей программой?
A>Это называется "отзывчивость UI". Люди, видишь, не машины, они секунды не складывают и доли не считают. Самая малая задержка вызывает сильный дискомфорт. Попробуй в ключевой OnButtonClick() добавить ::Sleep(2500); и засекай, через сколько юзеры начнут писать письма. A>Когда старый смартфон ИЗРЕДКА начинает откликаться на нажатия на полсекунды позднее, его выбрасывают.
Подмена понятий детектед. "Отзывчивостью UI" называется время реакции при выполнении типовых операций. Даже самый тупой юзер не пишет писем, когда дефрагментация диска занимает больше пяти секунд, и не выбрасывает телефон, когда обновление приложения занимает больше десяти.
Поэтому вопрос сохраняется: с какой частотой Вам требуется закрывать одно и то же приложение, что Вас так раздражает пара секунд на корректный выход?
A>Это реалии сегодняшнего дня, извини. Даже если кажется, что это избалованность. Как мне говорил один товарищ: я буду переплачивать за айфон сотни долларов, потому, что он всегда мгновенно откликается, а Андроид — не всегда. А потмо он же жаловался, что в новых Айфонах это сломали и он теперь ничем от Андроида не отличается. Так это или нет, я не в курсе, но это типичная юзерская потребность.
Как же меня это умиляет... Надо было десятки лет продвигать идеи вроде "нечего заморачиваться оптимизацией, проще подогнать железо помощнее", чтобы в конце концов обнаружить, что даже мощное железо не в состоянии вывезти то, что могут наворотить современные профессиоаналы, и приходится спасать положение, экономя на вызовах деструкторов.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Если "быстро" — это секунды вместо минут, то еще худо-бедно тянет на "оплаченные услуги". Если же это доли секунды вместо двух-трех секунд, то сколько раз в час нужно это проделывать, чтобы вообще возникла сама идея считать это благом?
Очень советую к ознакомлению. Становится понятно, что рассматривать надо не общее время работы, а удельную теплоту горения пользовательской жопы на одну миллисекунду задержки отклика интерфейса. И особенное внимание обратить на число лайков.
Даже если время загрузки не от нас зависит, то вот время выгрузки...
Мне-то оно зачем? Я сам регулярно пишу то же самое уже больше двадцати лет.
A>рассматривать надо не общее время работы, а удельную теплоту горения пользовательской жопы на одну миллисекунду задержки отклика интерфейса.
Не любого отклика, а по частоте использования. Тому, что используется раз в несколько часов, допустимо иметь ощутимую задержку. То, что используется регулярно, должно работать мгновенно, если это технически возможно.
Здравствуйте, Alekzander, Вы писали:
ЕМ>>То, что используется регулярно, должно работать мгновенно, если это технически возможно.
A>Например, закрытие Предлагаю согласиться хотя бы на этом.
Не понимаю, почему нужно соглашаться хотя бы на этом. Если программа открывается и закрывается много раз за час (редактор, утилита командной строки и т.п.) — это будет регулярным использованием, и действие будет ожидаться быстрым. Если же программа открывается/закрывается раз в сутки или реже, то кого реально напряжет, что она закрывается пять-десять секунд?
Умей они смотреть правде в глаза — перечислили бы навскидку с десяток куда более очевидных проблем, приводящих к тормозам везде и всюду. Но те проблемы трогать опасно — не дай бог выяснится, что тормозит как раз из-за перехода на технологию, которая несколько лет назад продвигалась в качестве передовой. А деструкторы были передовой технологией только в 70-80-х, с тех пор там не было никаких прорывов, так что можно наглядно продемонстрировать снижение тормозов за счет избавления от заведомо кривых деструкторов, но акцент сделать не на кривизне, а на якобы бесполезности деструкторов, как таковых.
