Очень долгое освобождение динамически выделенной памяти

[pproger]

2_Bers

Как видишь, гцц сказал: у чисто виртуальных методов не должно быть реализации.

в крестах такой синтаксис недопустим.
а вот такой вполне.
http://ideone.com/vMRUq

[pproger]

2_Bers

Как видишь, гцц сказал: у чисто виртуальных методов не должно быть реализации.

ты перевести хоть нормально можешь? там написано - pure спецификатор на определение функции. что недопустимо. вынести определение никто не мешает. в терминах крестов это все равно чисто виртуальная функция (как минимум потому, что задано = 0). в терминах логики она конечно не чисто виртуальная уже, ибо имеет тело (к которому кстати можно обращаться при переопределении в дочернем классе). так что то, что автор называет это чисто виртуальным деструктором вполне оправданно, хотя он и не знает, зачем это сделал.

http://ideone.com/ksu9M

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

пс. и да. ЕСТЕСТВЕННО у деструктора ДОЛЖНО быть тело (с этив вроде никто не спорил), не важно, чисто виртуальный он или нет. зачем деструктор делать чисто виртуальным я уже писал.

ппс. и хватит писать диструктор. destruction, а не distruction

[_Bers]

Вразумел.

Не знал, что так можно делать. На самом деле мне просто ни разу за всю практику не приходила идея выносить пустое туловище функции. На кой её выносить, если оно пустое?

А если оно не пустое, то тут уже не чисто-виртуальное просится.

Я почему то решил, что автору это тоже как бэ очевидно, и поэтому он не стал бы выносить пустое тело. Собственно, дальше декларации класса код не читал)))

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

[pproger]

2 _Bers

Не знал, что так можно делать. На самом деле мне просто ни разу за всю практику не приходила идея выносить пустое туловище функции. На кой её выносить, если оно пустое?

ты невнимательно читаешь посты. я выше писал, зачем это может понадобиться.

Собственно, дальше декларации класса код не читал)))

не читал, но осуждаю. понятно.

[_Bers]

Сообщение от pproger

2 _Bers
ты невнимательно читаешь посты. я выше писал, зачем это может понадобиться.

Какой смысл делать класс абстрактным в условиях, когда отсутствует чисто-абстрактный интерфейс?

Если у класса нет чисто-виртуальных функций, смысл делать его абстрактным?

[pproger]

2_Bers
запретить пользователю класса создавать от него объекты, только наследоваться. во всяком случае именно для этого была введена такая схема. как обычно в плюсах делается. никому не мешает - пусть будет. или - ну вроде удобно - пусть будет.

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

[_Bers]

Сообщение от pproger

2_Bers
запретить пользователю класса создавать от него объекты, только наследоваться. во всяком случае именно для этого была введена такая схема. как обычно в плюсах делается. никому не мешает - пусть будет. или - ну вроде удобно - пусть будет.

Да блин, зачем вообще такой запрет может понадобится??


Это может быть актуально для интерфейсов. Но класс, в котором отсутствуют чисто-виртуальные функции - это либо вообще не интерфейс, либо интерфейс, реализующий некие дефолтные/базовые для иерархии возможности.

На кой чорт запрещать создавать объекты такого класса?

[pproger]

2_Bers
ты опять невнимательно читаешь

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

class Person {
...
};

class Student : public Person {
};

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

зачем/почему у меня не спрашивай, я уже давно не пишу на крестах. читай дизайн и эволюция с++, там дохрый страус рассказывает, какие препараты принимал во время "проектирования" языка.


во, или в случае, когда чисто виртуальная функция имеет тело, в котором реализована часть функционала. остатки нужно добавить при наследовании и переопределении. не надо говорить, что можно эту часть вынести в невиртуальную функцию. свобода выбора. говнокодь как хочешь за это вроде бы все и любят кресты, не?

[_Bers]

Сообщение от pproger

2_Bers
ты опять невнимательно читаешь

Нет. Мое сообщение вышло позже по времени, чем твоё.
В момент его написание, сий текст ещё не был виден мною.

Сообщение от pproger

в процессе проектирования класса Person так уж вышло что у всех функций есть реализация, чисто виртуальные функции без реализации (которые обязательно нужно переопределить в дочернем классе) не нужны. но сам по себе объект класса Person смысла не имеет. да, он может ссылаться на дочерние и работать с ними, используя доступный ему интерфейс, но своих объектов иметь не может.

Одно дело, когда создание базовых объектов не имеет смысла. И совсем другое - когда их в принципе создавать нельзя.

Почему нельзя? Потому что, это может создать аварийную ситуацию.
Как нечто, что идеологически не является интерфейсом (либо является интерфейсом с дефолтной реализаций) может создать аварийную ситуацию?

Вопрос риторический. Теоретически, на плюсах можно наваять любое говно-арх, а потом приделывать костыли, что бы вся такая система не развалилась от первого же чиха. На практике, лично я ни разу не встречал. Имхо - сие есть ущербный костыль, невостребованный на практике. И если его кто и использует - лишь по незнанию, да неумению проектировать механизмы.


Отсюда вытекает другой, более реалистичный вопрос. Это уже не праздная философия:

Допустим есть некий механизм.
У него есть служебный метод. Который предоставляет механизму некоторые данные. Согласно проекту, этот метод не нужен клиентам механизма. Во всяком случае, для работы механизма клиентам даже знать про этот метод не обязательно.

Но! При этом, использование такого метода клиентами в любом случае не способно нанести ущерб инварианту механизма. Другими словами - этот метод абсолютно безобидный и безопасный.

Вопрос: нужно ли делать такой метод приватным (поскольку идейно он - часть реализации, а не интерфейса), или можно оставить публичным, поскольку его использование клиентами в любом случае безобидно и безвредно, а так - авось для чего нибудь клиентам и сгодится?


Вопрос: если запуски методов, или создание объектов неких служебных сущностей совершенно безобидно и безвредно для целостности системы, хотя возможно - лишено смысла, достаточный ли это повод для запрета использования?

Или нет никакого смысла тратить время, запрещая то, что в любом случае не способно создать аварийную ситуацию?


Я придерживаюсь мысли: подобного рода защита просто не имеет смысла. А следовательно, её конструирование - напрасная трата времени и денег компании.


Поэтому, я считаю, что не нужно запрещать то, что можно безопасно использовать. Даже если на первый взгляд, такое использование не имеет смысла.

Ну не имеет - ну никто и не будет тогда использовать. Проблем в любом случае не возникнет.

Реализации для чисто-виртуальных функций не имеет смысла. Равно, как не имеет смысла чиста-виртуальные диструкторы.

[pproger]

2_Bers
я тебя не пойму. ты мне что-то пытаешься доказать?) если тебе интересно мое мнение по данному вопросу - то нет, чисто виртуальные функции с телом не нужны. как и вызов delete на объект неполного класса. как и замыкание/каррирование по ссылке в лямбда функциях. как и сами лямбда функции в с++ (такое убожество, господи). как и куча других мест с неявным синтаксисом/опасным поведением. миллион таких мест в крестах. ибо язык такой. а ты начал разглагольствовать, зачем, почему. читай дизайн и эволюция, там многое проясняют, почему так, а не иначе.