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

мы вобще-то тут про си

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

Высрать можете вы, а бомбаунло у меня. Я сомневаюсь в вашей адекватности.

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

А документацию почитать, где всё это описано ты слишком горд? Вместо того, чтобы пользоваться проверенным кодом из стандартной библиотеки, где описано, какова сложность алгоритма ты изобретаешь непонятный велосипед, который надо бы оптимизировать (не только по временной сложности, но и непосредственную реализацию), да и тестировать тоже надо, ты же не машина и ошибки делаешь? Да, в документации есть места, где временная сложность указана как should, а не must или shall, тогда смотри в своей stl, разработчики должны указывать, если что-то не так, как должно быть, например разрабы gcc прямо пишут о таком.

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

объясни это разработчикам ядра, а главное Торвальдсу, он тебя закопает голыми руками за такие слова)

Проблема в том, что он это знает.

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

а ллвм, ну взяли плюсы и чо? а в ядро плюсы не взяли, че теперь, 1:1 чтоли?

Я не понимаю что я должен объяснить Торвальдсу. Всё что я хотел сказать это то что в упор не вижу как C++ ограничивает полёт фантазии по сравнению с си. Не говоря уж о том что C++ включает себя и си (с минорными различиями).

а ллвм, ну взяли плюсы и чо? а в ядро плюсы не взяли, че теперь, 1:1 чтоли?

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

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

Выдыхай :-) Все будет хорошо :-)

в упор не вижу как C++ ограничивает полёт фантазии по сравнению с си

BTW, именно из-за этого Торвальдс и не любит плюсы: полет фантазии слишкой большой, к тому же у многих программистов возникают довольно грязные фантазии

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

Скорее да, чем нет. Покажи, как используешь - скажу точнее=)

Абстрактный класс вообще без каких-либо реализаций чего-либо это интерфейс.

Вот именно. Потому в Java отдельные «интерфейсы»(при наличии абстрактных классов) и являются костылем, нужным только потому, что нет множественного наследования классов(в том числе и абстрактных).

С другой стороны, если у нас есть классы и интерфейсы, а так же (допустим) миксины или другой подобный механизм, то зачем нам вообще наследование классов?

а главное Торвальдсу

Если бы у Торвальдса были аргументы...

В мой адрес вы уже высрали два сообщения, адекватно ли это? Если вам не понравилось мнение другого человека, то пройдите мимо и как можно дальше. Это было бы адекватно.

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

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

Я так понимаю, что ты ни на одном из этих языков не пишешь активно? Тогда объяснить будет сложно. Но ты правда думаешь, что GCC перевели на плюсы потому что они «не осилили С»?

Имхо, плюсы «удобнее во всём». Основной аргумент против, который доводилось слышать - «слишком много всего ненужного». Это решает, если есть хотя бы минимальный контроль над проектом. А если нет, то там и на сишке и на чём угодно будет ад.

Это одна из двух фич языка, которая нарушает правило «ты не платишь за то, что не используешь».

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

Кстати, вторая фича какая?

Я так понимаю, что ты ни на одном из этих языков не пишешь активно?

твои фантазии никому не интересны

Тогда объяснить будет сложно

а ты постарайся, я со словарем

Но ты правда думаешь, что GCC перевели на плюсы потому что они «не осилили С»?

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

а в ядро плюсы не взяли, че теперь, 1:1 чтоли?

А погуглить? На то время плюсы были «не готовы» - кривые компиляторы и т.д. Вполне оправданное решение, на тот момент, было. Опять же, против Торвальдса не попрёшь. А принимайся решение не одним человеком - может что-то и изменилось бы, как с GCC.

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

Забавно, что даже на этом форуме часто ругают плюсы за то, что там есть «встроенные» реализации, скажем, ООП. И приводят в пример С, где «можно сделать как хочешь».

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

ТЫЦ (gnu.org)

все что там написано это well known, cleaner, easier

твои фантазии никому не интересны

Вообще-то это был вопрос, причём без негативного подтекста. И твой ответ весьма показателен.

а ты постарайся, я со словарем

Да причём здесь словарь. Все возможности плюсов можно на сишке повторить «без проблем». Дело как раз в удобстве, которое ощущаешь когда реально пишешь. А ты ведь заранее негативно настроен - будешь утверждать, что темплейты ничем не лучше макросов, что от RAII помощи мало и т.д.

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

«Проще» как раз вряд ли. А если тебе интересно, то возьми да погугли. Благо про переход информации много. Будут тебе реальные аргументы от разработчиков, а не мой пересказ.

как мы ловко перешли от первоначального вопроса

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

к «ты не знаешь ни того ни другого», «я щитаю», «объяснить будет сложно», кококо

Ты на самом деле такой тупой, или просто решил тут всех затроллить?

И приводят в пример С, где «можно сделать как хочешь».

Тогда надо писать на асме и без библиотек.

Нормальные реализации не добавляют оверхеда, если исключение не бросается реально

Ещё как добавляют, ты сравни размер бинарника с -fno-exceptions и без.

Кстати, вторая фича какая?

RTTI

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

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

я тут приводил Торвальдса в пример как человека, осилившего нормальную архитектуру на сишке и не плачущего за «проще, легче, well known, кококо»

В этом треде, ты мне напоминаешь царя и emuleka в одном лице. :)

иди ка ты туда, там твои братья по разуму

Курить Гослинга - Глава 3.7

http://rutracker.org/forum/viewtopic.php?t=2702714

До полного просветления.

Я уже давно там!

в чем моя тупость?

Давай разберемся.

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

Хорошо, что ты хоть понимаешь.

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

Но это, очевидно, никак не связано с языком, на котором он писался.

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

Но это, очевидно, никак не показывает, что разработчики gcc считают С++ проще и выразительнее.

я бы не стал кукарекать, что писатели гцц не осилили сишку

Но ты это делаешь ниже.

но они реально не осилили запилить архитектуру на сишке

Но сложность реализации нетривиально архитектуры вовсе не недостаток С, очевидно.

вот и взяли что-то попроще

Но выбирать более простой и выразительный язык при прочих равных - признак слабости духа, очевидно.

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

У llvm сразу получилась аккуратная и выразительная архитектура, но причина не в языке, просто разработчики llvm - высококвалифицированные профессионалы. Тогда правда непонятно, почему высококвалифицированные профессионалы пишут на С++ а не на С, ведь проблема не в языке изначально.

Торвальдса в пример как человека, осилившего нормальную архитектуру на сишке

Значительная часть этой архитектуры основывается на ручной реализации подмножества С++, но дело не в языке изначально.

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

Всякий раз, когда у меня возникала необходимость во множественном наследовании, я обнаруживал, что к меня просто кривые руки в плане проектирования. Я с подозрением к нему отношусь. Если в нем возникла необходимость, я всегда подозреваю, что «объектная модель» слишком прямолинейно построена, и что она не адекватна решаемой проблеме.

Ещё как добавляют, ты сравни размер бинарника с -fno-exceptions и без.

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

RTTI

Ну при желании можно «не платить» (-no-rtti).

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

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

A u serious?

4.8

Всякий раз, когда у меня возникала необходимость во множественном наследовании, я обнаруживал, что к меня просто кривые руки в плане проектирования. Я с подозрением к нему отношусь. Если в нем возникла необходимость, я всегда подозреваю, что «объектная модель» слишком прямолинейно построена, и что она не адекватна решаемой проблеме.

А может быть твоя архитектура стала бы еще лучше, если бы ты вообще отказался от наследования конкретных классов и использовал только интерфейсы/абстрактные классы + миксины/делегирование/trait+impl/etc.?

А может быть твоя архитектура стала бы еще лучше,

Это не просто «может», это очевидно

Очевидно! Я понимаю, когда есть готовые конкретные классы, изменять их нельзя, и наследоваться от них это самый дешёвый вариант. Но когда все в твоих руках лучше просто не страдать херней множественного наследования реализаций. На самом деле, даже простое наследование реализаций нужно не очень часто.