Зачем нужны абстрактные классы?

костыль, который нужен когда нет интерфейсов

Интерфейсы это костыль когда нет множественного наследования.

Абстрактный класс нужен, чтобы было от чего наследоваться, когда эмулируешь тип-сумму в ООП.

В абстрактном классе могут быть реализованы некоторые методы, могут иметься поля.

зависит от религии. некоторые евангелисты программируют по принципу «все классы либо абстрактные, либо финализированные».

Встречный вопрос: что такое Protected Abstract Virtual Base Pure Virtual Private Destructor и зачем оно надо?

Затруднившимся ответить предлагается вопрос полегче: зачем нужны плюсы?

зачем нужны плюсы?

Писать на них программы.
Искренне ваш,
Кэп.

зачем нужны плюсы?

поддерживать легаси-говнокод.

поддерживать легаси-говнокод.

Да, что бы с помощью этого легаси-говнокода вы могли высрать свой коммент на ЛОРе.

Да, что бы с помощью этого легаси-говнокода вы могли высрать свой коммент на ЛОРе.

Скоро можно будет срать ржавчиной)

Скоро можно будет срать ржавчиной)
Скоро

Ага, сразу после того, как взлетят D и Perl 6.

каким местом плюсы к лору?

Браузер, в котором ты на ЛОРе сидишь, на чём по-твоему написан?

слабенько, есть броузеры на чистом си, links, например

links

И ты правда им пользуешься?

в нём есть что-то, что делает его очень полезным?

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

Посмотрим, по крайней мере попытки мозилки ушли уже за пределы компилятора.

Интерфейсы это костыль

Нет.

нет, да

Интерфейсы это костыль когда нет множественного наследования.

Плюсую.

каким местом плюсы к лору?

Каким местом вы родили этот вопрос?

зачем нужны плюсы?

Е**ть и плакать, очевидно же. Говноязык, без которого никуда не денешься. И это хреново.

а зачем ты слово «есть» запикал?

http://pastebin.com/55hTRxAd

Да, что бы с помощью этого легаси-говнокода вы могли высрать свой коммент на ЛОРе.

Я на любом языке, у которого есть хттп клиент, могу высрать коммент на ЛОРе. Почему у Вас так бомбануло?

зачем нужны плюсы?

gcc и llvm писать, например.

костыль, который нужен когда нет интерфейсов и трейтов

Да.

Это полноценный базовый класс, предназначенный для того, чтобы от него наследовались и при этом не предназначенный для непосредственного использования

Объяснишь, чем плюсы лучше в написании компиляторов чем сишка? Я вот в универе писал компилятор на сихе и ниче. Был выбор взять плюсы или сишку и на плюсах задача решалась проще, если не понимать, что делаешь досконально. Тоесть если не умеешь работать с деревьями, бери плюсы.

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

чем плюсы лучше в написании компиляторов чем сишка?

Ты сам ответил:

на плюсах задача решалась проще

А вот это непонятно как понимать:

если не понимать, что делаешь досконально

По твоей логике си это для тех кто не осилил асм.

си это для тех кто не осилил асм

А асм — для тех, кто не осилил машкод

Правильно ли я понимаю что это просто костыль, который нужен когда нет интерфейсов и трейтов, или в нём есть что-то, что делает его очень полезным?

Смотря где и смотря как сделано. В Java, наоборот, костылем являются интерфейсы, которые существуют в одном языке вместе с абстрактными классами, а введены были только для обхода множественного наследования.

В C++ - это просто один из видов классов, т.е. Страуструп смог добиться нужного, без введения дополнительных понятий в духе «интерфейс», «трейт» и пр.

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

если не умеешь работать с деревьями, бери плюсы

Какой бред.

оно таки компилировало и работало.

Прикинь, раньше компиляторы писали на Фортране. Фортране-II, если что. И оно тоже компилировало и работало.

А вот это непонятно как понимать:

так же как

на плюсах задача решалась проще

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

если все равно не понятно: в сишке нет ничего готового, а в плюсах, к примеру, есть за тебя написанные структуры данных и ты вместо того, чтобы писать как хочешь, пишешь как дали

что сказать-то хотел? ты специально мне отвечаешь какую-то муть, а всем остальным нормально?

и ты вместо того, чтобы писать как хочешь, пишешь как дали

Ну бред же, никто тебя ни к чему не принуждает. Хочешь — пиши свои деревья, узко заточенные под твои нужды, в большинстве сложных случаев так и делают. Стандартная библиотека просто упрощает решение повседневных задач. В сишке ты тоже сортировку каждый раз сам пишешь вместо qsort?

Видимо чем-то лучше, раз ребята из gcc пошли на перевод 30-летней кодовой базы с С на С++.

Тоесть если не умеешь работать с деревьями, бери плюсы.

Если нет желания тратить время на изобретение велосипедов, бери плюсы.

Хочешь — пиши свои деревья, узко заточенные под твои нужды, в большинстве сложных случаев так и делают.

Стандартная библиотека просто упрощает решение повседневных задач.

взаимоисключающненько, все еще нет аргументов в пользу плюсов

В сишке ты тоже сортировку каждый раз сам пишешь вместо qsort?

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

Какие все самые умные! :-)

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

В С++ умышленно поддерживается множественное наследование. Как поведения так и реализации. В Java умышленно множественное наследование реализации не поддерживается, а множественное наследование поведения поддерживается.

Интерфейс это не костыль и не замена множественному наследованию, а отдельная методика проектирования.

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

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

Если нет желания тратить время на изобретение велосипедов, бери плюсы.

компилятор это и есть один большой велосипед, в таком коде реюз не нужен

не нужен он потому, что дефот он обычно довольно general solution, тогда как в компилере надо узко под задачу в зависимости от архитектуры

чем плюсы лучше

raii, exceptions, templates.

exceptions

Как раз это спорный момент. Во многих крупных проектах исключения либо не используются вообще, либо их использование сильно ограничено. Это одна из двух фич языка, которая нарушает правило «ты не платишь за то, что не используешь».

Да. Тред не читал.

без знания его асимптотической сложности

Сложность всех методов в stl определена в стандарте.

ты увидишься, если я скажу, что баблсорт на мелких инпутах работает быстрее квиксорта?

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

в сишке нет ничего готового

Если это плюс то я китайский лётчик.

вместо того, чтобы писать как хочешь, пишешь как дали

Пардон, но это бред со всех сторон.

реюз не нужен

Объясни это ребятам из gcc, которым видимо надоело велосипедить каждый раз одни и те же структуры данных. Казалось бы, уж кто лучше них должен понимать всю выразительную мощь чистого С. А еще лучше посмотри на код llvm, который изначально писался на С++.

тогда как в компилере надо узко под задачу в зависимости от архитектуры

Ты о чем вообще?

за сколько аккаунт купил?

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

В абстрактном классе нет реализации(в большинстве случаев), что ты собрался наследовать?

Интерфейс это не костыль и не замена множественному наследованию, а отдельная методика проектирования.

Конкретно в Java - костыль. Т.к. если есть абстрактные классы и множественное наследования, то отдельная языковая сущность «интерфейсы» не нужна. Но если мы в угоду обезьянкам запретим множественное наследование, то нам приходится извращаться.

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

Требую примера.

instanceof тоже костыль?