LINUX.ORG.RU

ооп и функциональщина кратко, внятно.

 , , ,


11

7

Дабы не слать напраслину на любителей создавать классы и объекты, пытаюсь разобраться в плюсах, которые отличаются от родителя, на первый взгляд, только названиями файлов, функций и приемами организации мышления погромиста. Так вот, эти ваши классы даже в учебнике называют почти структурами, а мизерное отличие сомнительного профита легко можно решить и в анси си(далее - ансися) при ближайшем обновлении. Ансися страдает перегрузкой названий функций для каждого из подлежащих обработке типов, отсутствием удобной иногда перегрузки функций, что, конечно минус, но не критично, ибо решаемо. Сиплюсик конечно удобен школьникам, тяжело принимающим всякие %s %d %x и так далее в качестве аргументов принтфов и сканфов, но зачем создавать для этого отдельный язык? Ведь << и >> становится лишним препятствием при освоении, если параллельно сдвиги битов читать. Итого, я вывел для себя, что в попытке облегчить участь программиста, разработчики языка усложнили его до степени родителя, не получив особенного профита. Чем же ооп так всем нравится, если оно не облегчает код?

★★★★★

Последнее исправление: cetjs2 (всего исправлений: 1)
Ответ на: комментарий от qulinxao

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

Не-а! Ведь ООП лежал, лежит и будет лежать исключительно в практической плоскости. А раз так, то все опять и снова упирается в реализацию.

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

Но меня всегда поражало другое. Почему, ну почему никто не сделал «промышленной» реализации ML, которая бы позволяла писать низкоуровневые программы? Т.е. без десятка стадий кодогенерации (пусть даже в ущерб производительности, пусть даже с ликвидацией магии System F). С возможностью ручного управления памятью. Причем ML за нефиг делать позволил бы рулить режимами (а на что нам еще монады?). С максимальным упрощением рантайма, и с возможностью максимальной его конфигурации вплоть до режима «не тащить с собой». С безусловной ориентацией на интеграцию с C.

Macil ★★★★★
()
Ответ на: комментарий от tailgunner

Корчеватель в треде!

Если писать «нормальным языком», получится книжка размером с Буча... Оно тебе надо?

Macil ★★★★★
()
Ответ на: комментарий от Macil

Если писать «нормальным языком», получится книжка размером с Буча... Оно тебе надо?

Нет. Но корчеватель-стайл дамп мне тоже не нужен.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Но корчеватель-стайл дамп мне тоже не нужен.

А ты добавь хороших задачек. И будет по Константинову.

Macil ★★★★★
()
Ответ на: комментарий от stevejobs

А зачем как в лиспе? В лиспе все тормозит :) Вот как в скалке еще можно было бы. Там не так давно появились макры и будут развиваться. Насколько я вижу, они учли опыт nemerle.

anonymous
()
Ответ на: комментарий от thesis

Указатели не позволяют сделать в языке перегрузку операторов. Собственно, ссылки появились в С++ из-за перегрузки операторов.

И еще, в С формально не выразим тип результата *ptr. А это именно ссылка.

anonymous
()
Ответ на: комментарий от encyrtid

Алан врет. ООП было до него, а Страуструп свой С с классами делал примерно в то же время, когда Кей придумывал. Страуструп брал ООП концепции с Simula67.

anonymous
()
Ответ на: комментарий от anonymous

Какой smalltalk? Он не востребован от слова совсем.

anonymous
()
Ответ на: комментарий от emulek
Matrix &Matrix::operator+(const Matrix &B) const

И что тут сложного(ты неправильно написал, но фиг с ним)? На С будет чем-то лучше?

anonymous
()
Ответ на: комментарий от ilammy

Некоторым людям™ не нравится, что строка «i++» не очевидно показывает «мы тут переходим к следующему элементу дерева».

Боюсь, что они профнепригодны. Я боюсь, что с ними будет при изучении scala, например.

anonymous
()
Ответ на: комментарий от anonymous

Есть pragma pack(1) и функции для перевод из одного порядка байтов в числе в другой. Никаких проблем.

anonymous
()

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

anonymous
()
Ответ на: комментарий от ilammy

Пока реализации скалки это не позволяют. А вот на С++ - пожалуйста. Так чем плоха концепция перегрузки операторов? Она вводит стандартные имена для стандартных операций, она позволяет писать более наглядный код, она позволяет делать dsl... А недостатки какие?

anonymous
()
Ответ на: комментарий от anonymous

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

особенно наследование :(

qulinxao ★★☆
()
Ответ на: комментарий от anonymous

Алан врет. ООП было до него, а Страуструп свой С с классами делал примерно в то же время, когда Кей придумывал. Страуструп брал ООП концепции с Simula67.

Прочти пост еще раз.

encyrtid ★★★★★
()
Ответ на: комментарий от emulek

как раз таки нет , в отличии от «нормальных языков» для наследования в С++ тебе при компиляции потребуется сырцы родителя , что просто напросто «обнуляет» пользу наследования.

ибо вот так.

qulinxao ★★☆
()
Ответ на: комментарий от qulinxao

Он всегда бредит. Не обращай внимания. У меня он вообще вот так подписан:

emulek (23.08.2013 2:21:16) гиперактивный генератор бреда

geekless ★★
()

Сиплюсик конечно удобен школьникам, тяжело принимающим всякие %s %d %x и так далее в качестве аргументов принтфов и сканфов

Фишка в том, что те же printf и scanf не проверяют типы и количество передаваемых аргументов, создавая огромное поле для багов и уязвимостей, а также не расширяемы, т.к. набор выводимых типов жестко ограничен.

Ну и к ООП и функциональщине топик не имеет абсолютно никакого отношения.

annulen ★★★★★
()
Ответ на: комментарий от minakov

тайпдефы ... портят читаемость

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

annulen ★★★★★
()
Ответ на: комментарий от annulen

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

Типы printf и scanf проверяют компиляторы уже сколько лет... 10-15?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

geekless ★★
()
Ответ на: комментарий от geekless

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

О чем ты? Если о printf-подобных строках форматов, то в приличных компиляторах валидатор уже есть.

tailgunner ★★★★★
()
Ответ на: комментарий от Macil

1. Класс - химера. Объединяет в себе «тип», «интерфейс», «поведение».

Легковой автомобиль - химера. Объединяет в себе «бензин», «двигатель» и «ходовую часть».

2. Тип. В данном конкретном случае то же самое что и множество. Т.е. class Foo <==> все объекты класса Foo принадлежат множеству Foo.

детский сад, штаны на лямках

т.е. по-твоему «кольцо целых чисел» и «аддитивная группа целых чисел» это один и тот же тип? множества ведь совпадают

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

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

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от tailgunner

О чем ты? Если о printf-подобных строках форматов, то в приличных компиляторах валидатор уже есть.

О не printf-подобных строках форматов.

geekless ★★
()
Ответ на: комментарий от tailgunner

Типы printf и scanf проверяют компиляторы уже сколько лет... 10-15?

gcc на это выдает только варнинг, и только с -Wall

annulen ★★★★★
()
Ответ на: комментарий от geekless

Если о printf-подобных строках форматов, то в приличных компиляторах валидатор уже есть.

О не printf-подобных строках форматов.

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

tailgunner ★★★★★
()
Ответ на: комментарий от Deleted

Поэтому ядро пишут на плюсах?

ядро чего? линукса что ли?

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

алгебраическая структура

А по-твоему класс - алгебраическая структура?

И не понял возникшего баттхерта. Поясни.

Macil ★★★★★
()
Последнее исправление: Macil (всего исправлений: 1)
Ответ на: комментарий от tailgunner

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

geekless ★★
()
Ответ на: комментарий от geekless

КО имеет сказать, что пост annulen-а говорил как раз о том, что эти проверки в случае крестов должен и может выполнять тайпчекер

Передай КО, чтобы читал внимательнее.

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

Не понял, в чем твоя претензия. Я даже слово «валидатор» использовал в ответ на:

geekless> писать валидатор в составе компилятора?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

А тем временем в iostream, вместо проверки соотвествия аргументов строке формата, происходит подбор нужной функции под тип аргумента, что а) убирает лишнюю сущность - тип в строке формата; б) предотвращает ошибки из-за несовместимости типов; в) работает даже в шаблоне, когда тип может меняться

annulen ★★★★★
()
Ответ на: комментарий от geekless

Всего два слова: https://www.kernel.org/ и https://developer.gnome.org/glib/2.32/

слова писать ты научился, молодец — теперь осталось прочитать что я написал:

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

и включить мозги

оба этих проекта находятся на разных стадиях движения к «личному с++»; этот «личный с++», хотя может быть даже более удобен для этих проектов, чем с++, оказывается существенно менее пригодным (или даже вообще не пригодным) для других проектов

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от annulen

Мне, в общем-то, безразличны прелести iostream. Я прокомментировал конкретную фразу о непроверяемости аргументов printf и scanf.

А противники форматных строк могут подумать на досуге, почему форматные строки вернулись в D, Scala и Rust.

tailgunner ★★★★★
()
Ответ на: комментарий от Macil

А по-твоему класс - алгебраическая структура?

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

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

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

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

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от qulinxao

Да, возможно именно с пониманием/использованием наследование у ТС(и вас?) и возникли трудности. Как вы решаете вопрос с принципом открыт-закрыт? Есть еще подход со сигнатурами/структурами в ML'ах, например. Он вам больше нравится? Но ведь он работает на один уровень фактически. Кроме того, не связан с типами, к нему не применим LSP и др. полезные принципы.

anonymous
()
Ответ на: комментарий от tailgunner

Как мне добавить формат для своего типа? В С++ это делается легко и непринужденно.

anonymous
()
Ответ на: комментарий от Macil

И не понял возникшего баттхерта. Поясни.

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

это на 2-м курсе обычно и объясняют... или даже на 1-м, уже забыл

www_linux_org_ru ★★★★★
()
Последнее исправление: www_linux_org_ru (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Форматные строки в перечисленных тобой языках очень сильно отличаются от сишечки. Ибо типобезопасны и расширяемы. В С++ типобезопасность и расширяемость были обеспечены через перегрузку операторов, ибо это просто и работало еще на основе достаточно старых правил перегрузки. Далее появился boost::format, например. С использованием нового стандарта можно без проблем реализовать printf типобезопасно и расширяемо. Сишечке это не по зубам.

anonymous
()
Ответ на: комментарий от anonymous

наследование не нужно.

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

вообще интерфейсов достаточно.

qulinxao ★★☆
()
Ответ на: комментарий от qulinxao

Интерфейсов недостаточно. Достаточно интерфейсов + «миксинов»(в том или ином виде). Но это часто превращает потенциально простой код в непонятную лапшу.

anonymous
()
Ответ на: комментарий от anonymous

Форматные строки в перечисленных тобой языках очень сильно отличаются от сишечки.

Спасибо, Капитан, я знаю.

Ибо типобезопасны и расширяемы.

В GCC форматные строки так же типобезопасны, как и всё остальное в Си. Не расширяемы, да (точнее, расширяемы, но расширения уже не типобезопасны, ЕМНИП).

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.