cd_riper (cd_riper) wrote,
cd_riper
cd_riper

Categories:

Горе от ума

Прочитал на хабре веселую статью под названием "Как безопасно разрушить объект. И другие мысли"
http://habrahabr.ru/blogs/cpp/110850/

Собственно "безопасно разрушить объект" это про классические, тысячу раз пережеванные, грабли, когда тип имеет не виртуальный деструктор и при этом экземпляры этого типа пытаются удалять через указатель на базовый класс (многие компиляторы умеет отслеживать подобную проблему и выдают соответствующие предупреждения).

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

Но вернемся к нашим баранам.
Как вам, к примеру, такой мощный вывод нашего гения?
"Полиморфное удаление — подозрительная штука"

Этот бред даже комментировать не хочется. Это сразу к специалистам, чей профиль добрая болезнь паранойя.

Виртуальные методы у нас, оказывается, порождают "накладные расходы и накладывают ограничения". Знаете о каких ограничениях идет речь? Ни за что не догадаетесь! Объекты с виртуальными методами нельзя использовать в объединениях! Ой, ой -- автору в следующий раз надо обязательно написать про "некоторые мысли" о полезности объединений.

Нет, я не против NVI. Эту политику я сам всеми силами одобряю, дык не стоит путать хрен с пальцем и доводить любое правильно до маразма, возводя в абсолют! Автору правильно написали: "только не надо забывать что деструктор — это чисто техническая вещь, к обязанностям интерфейса класса он как правило не имеет ни малейшего отношения".

Вместо того, чтобы рассуждать на тему "должен ли быть деструктор public или protected" я бы на месте автора лучше бы написал о том, что наследование в хороших программах используется довольно редко, т.к. композиция значительно более полезный подход (при этом я, разумеется, не отрицаю повсеместной "реализации интерфейсов", которая в плюсах технически сводится к тому же наследованию).
Или может лучше автор написал бы о том, что хороший деструктор, это деструктор, которого вообще нет. А за деструктор, в котором пишется "delete" нужно обрывать человеку руки-ноги...

Рекомендация "избегать виртуальных методов" ничего кроме желания покрутить пальцем у виска не вызывает. С одной стороны, вряд ли мало-мальски опытный программист будет этой виртуальность злоупотреблять. А с другой -- в плюсах виртуальные методы это фактически единственный способ определять разное поведение в runtime (switch по какому-то полю мы всерьез не рассматриваем, ведь верно?). Как вообще можно "пересмотреть" дизайн практически любой реальной программы, чтобы в ней был минимум такого "подозрительного" поведения??

Вот вам на 100% типичный, встречающийся во множестве реальных программ, пример с использованием виртуального удаления, взятый из подсистемы, над которой я в данным момент работаю.
Есть класс "голосовой канал". Под капотом у него есть "кодек", который определяется в runtime во время установления связи с удаленной стороной. Голосовых кодеков в природе существует воз и маленькая тележка. Все очевидно и просто -- есть фабрика кодеков, которая по ID создает соответствующий объект и возвращает его в виде IVoiceCodec. Этот интерфейс голосовой канал сохраняет себе в scoped_ptr и дальше с помощью него реализует свою функциональность. В деструкторе, понятное дело, происходит то самое виртуальное удаление. Чем это удаление "подозрительно"? Чем плох такое дизайн?

На эти вопросы мы вряд ли получим вразумительные ответы от автора, любящего строить свои аналогии на теме МКАДа и асфальтоукладки.

зы. Автора конкретно бомбят в комменатах:

"Хорошая статья — удачное жонглирование псевдологикой. Элементарные и корректные примеры… не относящиеся к теме. Все остальное — метафоры, «не вызывает ни у кого сомнений», «не есть хорошо и может выйти вам боком» и прочие откровения британских ученых.
Единственный корректный аргумент во всей статье — не может использоваться в объединениях. Ну ради объединений не грех отказаться от ООП."


или

"у меня от статьи когнитивный диссонанс какой-то, простите.
А может это вброс такой?"
Tags: c++, programming
Subscribe

  • Про API

    Евгений Кирпичев затронул тему, о которой рано или поздно задумывается любой мало-мальски опытный программист -- тему о том, должен ли быть доступ к…

  • Судьба

    Советский Союз, хоть и вышел первым в космос, был крайне отсталым государством в IT отрасли -- в свое время было принято решение ни хрена самим не…

  • Загрузочное

    В этой заметке хочу написать об околозагрузочных вещах, которые мы делали в рамках нашего проекта на основе камня от Analog Devices BF-537 (семейство…

  • Post a new comment

    Error

    Comments allowed for friends only

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 81 comments

  • Про API

    Евгений Кирпичев затронул тему, о которой рано или поздно задумывается любой мало-мальски опытный программист -- тему о том, должен ли быть доступ к…

  • Судьба

    Советский Союз, хоть и вышел первым в космос, был крайне отсталым государством в IT отрасли -- в свое время было принято решение ни хрена самим не…

  • Загрузочное

    В этой заметке хочу написать об околозагрузочных вещах, которые мы делали в рамках нашего проекта на основе камня от Analog Devices BF-537 (семейство…