В чём суть ООП?

Когда ты пишешь printf(«%..., тебе надо ломать голову, что тут ставить вместо многоточия. Используя полиморфизм тебе не нужно задумываться также о типе данных, просто пишешь cout << x, и оно самом разбирается, что делать с этим x

крайне неудачный и глупый пример. „cout << x“ не разберётся как и что нужно выводить, в этом продходе просто нет эквивалентной замены форматированного вывода. Я прежде всего говорю о циферках a и b в »%a.b" и различных представлениях float чисел. Сишный подход не идеален, но ООП-подобные варианты через '<<' чудовищны и неудобны.

Это просто многое говорит о знании оппонентом ЯП

не обязательно. В php printf() это часть ЯП.

cout << x, да :)

Сишный подход не идеален, но ООП-подобные варианты через '<<' чудовищны и неудобны.

это не удивительно. Проблема в том, что встроенные типы int, double, etc кривые в C++ by design, если их рассматривать как типы. Потому их и не распечатать по-человечески. cout << x это вообще НЕ ООП, ибо в ООП следует писать x->print(), ибо ООП это ОБЪЕКТНО ориентированное программирование, и сл-но надо отправить message объекту, т.е. x'у. Пусть объект и думает. Ну а авторы STL сделали «объектом» НЁХ под названием cout. ИМХО IRL cout годно только для отладочной печати, да и то я юзаю fprintf(3) для этого.

Не так уж просто, если для типа переменной x вдруг не окажется подходящего <<

я тег [тонкий троллинг] забыл поставить (:

Сишный подход не идеален, но ООП-подобные варианты через '<<' чудовищны и неудобны.

Недавно наткнулся на противоположное мнение кстати (пункт 2. Printf).

<subwoofer (22.09.2012 23:54:54)> наследование порождает кучу проблем

<drBatty * (23.09.2012 0:01:59)> расскажи мне пожалуйста, каким образом в C++ мне реализовать полиморфизм и абстракцию, без наследования от абстрактных базовых классов?

<LamerOk ***** (23.09.2012 0:04:39)> Через шаблоны. К.О.

в ЯП Go — нет — ни Абстрактный классов (ни вообще классов), ни наследования, ни шаблонов...

...если хотите сказать в Go нет полиморфизма, то ошибаетесь.. он там очень комфортный.

Недавно наткнулся на противоположное мнение кстати (пункт 2. Printf).

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

какое-то бла-бла-бла на тему предпочтения формы вместо решения практической задачи.

Добро пожаловать в ООП.

ООП не в этом. Просто в популярных ООП языках оно так сделано, вот и все.

Отчего-то мне казалось, что ключевым моментом является «объект». Так в чем же оно? Желательно без подмены способа/подхода (ооп) на цель (инкапсуляция etc.).

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

Там вроде ссылка была:

... there are smarter ways that don’t require compiler kludges

Ну, и как? Разобрались в чем суть ООП?

Добро пожаловать в ООП.

верблюдопроблемы.

получается, у каждого - своя. У ГОглуфанбоев так вообще ничего нет из ООП, а ООП есть. ИЧСХ - уютное. Так то.

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

а авторы STL сделали «объектом» НЁХ под названием cout

cout - это не STL, это iostream. авторы у них разные

угу. согласен. Впрочем, авторы STL тоже НЁХ навернули.

в ЯП Go — нет — ни Абстрактный классов

не совсем. во всяком случае, с точки зрения C++

Эм, а при чем тут ООП? Про printf я привел пример, чтобы указать на то что инкапсуляция - это базовая концепция программирования в принципе,а не только ООП. Я printf к ООП не причислял=)

cout << x это вообще НЕ ООП, ибо в ООП следует писать x->print()

Тебе кто такую ерунду сказал?

Утиная типизация пошла от поговорки «Если что то крякает как утка, летает как утка и выглядит как утка, то это, вероятно, утка». Если в языке можно написать функцию, принимающую любой аргумент с методом .length() и оператором [], то в нём есть утиная типизация. В C++ это можно сделать с шаблонами, правда сгенерированный код почти наверняка будет сдублирован; да и concepts пока в стандарт не вошли.

Это все-таки сильно не абстрактные классы. Даже от традиционных (ООП-)интерфейсов заметно отличаются, этакая смесь хаскелльных тайпклассов и обобщенных функций CLOS. И не говори, что с ними можно сделать то же самое, что и с абстрактными классами, стиль организации кода и вообще будет сильно другой.

Я тоже :)

Впрочем, авторы STL тоже НЁХ навернули.

STL это тащемта обобщенное программирование, а не ООП :) Аффтар фанатов ООП троллил, называя ООП «раздутой фальшивкой» :)

«Вопрос: Я думаю, STL и Generic Programming отмечают определенный отход от общепринятого стиля программирования на C++, который я нахожу почти полностью выведенным из языка SmallTalk. Согласны?

Степанов: Да. STL не является объектно-ориентированным. Я думаю, объектно-ориентированность является почти такой же раздутой фальшивкой (hoax), как и теории искусственного интеллекта. Мне еще не попадался интересный кусок кода, который пришел бы от этих объектно-ориентированных людей.» (с)

Основа программирования — абстракция. Все остальное это уже шелуха сверху.

// Разумеется, на самом деле не нужно быть столь категоричным

интересный кусок кода

Пусть посмотрит на внутренности Smalltalk VM.

Суть в buzzzzzzzzzzzz...

Это все-таки сильно не абстрактные классы

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

стиль организации кода и вообще будет сильно другой

например?

крайне неудачный и глупый пример. «cout << x» не разберётся как и что нужно выводить, в этом продходе просто нет эквивалентной замены форматированного вывода. Я прежде всего говорю о циферках a и b в «%a.b» и различных представлениях float чисел. Сишный подход не идеален, но ООП-подобные варианты через '<<' чудовищны и неудобны.

в этом продходе просто нет эквивалентной замены форматированного вывода

Погромисты С в треде, все в машину. В машину? OH SHI~

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

// -*- compile-command: "g++ cout.cpp -g -std=c++0x -o cout && ./cout" -*-
#include <iostream>
#include <iomanip>
#include <cstdio>

int main(int argc, char *argv[])
{
    float foo = 31.12345;
    printf("%8.3f\n", foo);

    // same, using std
    std::cout << std::fixed << std::setw(8) << std::setprecision(3) << foo;
    return 0;
}

Причём, что характерно, точность и многие другие параметры (флаги ввода-вывода и т.п.) можно выставить один раз, и использовать для всего вывода в дальнейшем. То есть плюшки ООП подхода.

Потому их и не распечатать по-человечески. cout << x это вообще НЕ ООП, ибо в ООП следует писать x->print(), ибо ООП это ОБЪЕКТНО ориентированное программирование, и сл-но надо отправить message объекту, т.е. x'у. Пусть объект и думает. Ну а авторы STL сделали «объектом» НЁХ под названием cout. ИМХО IRL cout годно только для отладочной печати, да и то я юзаю fprintf(3) для этого.

Ещё один специалист. Хотя чего ожидать от человека, не осилившего пакетный менеджер?

Вот скажи, а если у меня есть объект точка (пара координат), и я хочу её вывести в консоль, на поверхность в OpenGL, отправить по сети и т.п., мне надо добавить все соответствующие методы в класс точки, да?

Эм, а при чем тут ООП?

ООП это тоже базовая концепция, которая логически следует из инкапсуляции. Следующая ступень развития. ИМХО.

в ООП следует писать x->print()

Тебе кто такую ерунду сказал?

никто не говорил. у меня своё мнение имеется. А что не так?

Утиная типизация пошла от поговорки

та я уже понял... вот здесь хорошо написано, с понятными примерами.

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

ИМХО нельзя. По той же причине, по которой нельзя делать невиртуальные деструкторы.

Степанов

ага. Ещё из него-же:

Я нахожу объектно-ориентированное программирование философски нездоровым. Оно утверждает, что всё является объектом. Даже если это так, это не очень интересно: сказать, что всё является объектом — значит, не сказать вообще ничего. Я нахожу объектно-ориентированное программирование неправильным методологически. Оно начинается с классов. Это как если бы математик начал с аксиом. Вы не начинаете с аксиом — вы начинаете с доказательств. Только когда вы нашли кучу соотносящихся доказательств, вы предлагаете аксиомы. Вы заканчиваете аксиомами.

То же справедливо и в программировании: вы должны начать с интересных алгоритмов. Только когда вы хорошо их понимаете, вы можете предложить интерфейс, который позволит им работать.

ИМХО - типичная позиция типичного математика-теоретика. Вопрос времени-денег его волнует мало, это для него мелочь, по сравнению с методологией.

И да. STL и темболее iostream настолько низкоуровневое, что и не может быть ООПшным. Опять-таки - ИМХО конечно.

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

твои манипуляторы, суть - костыли.

printf(«%8.3f\n», foo);

std::cout << std::fixed << std::setw(8) << std::setprecision(3) << foo;

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

Ещё один специалист. Хотя чего ожидать от человека, не осилившего пакетный менеджер?

выдыхай, анон. ПМ я давно осилил, и от него отказался. Не люблю, когда за меня делают мою работу. Например я до сих пор не понял, зачем на моём боевом сервере ttf шрифты для иксов? А таки вытянулись по зависимостям.

Вот скажи, а если у меня есть объект точка (пара координат), и я хочу её вывести в консоль, на поверхность в OpenGL, отправить по сети и т.п., мне надо добавить все соответствующие методы в класс точки, да?

не знаю. Зависит от задачи. Если у тебя есть работник, личное присутствие которого требуется в твоём офисе, то кому ты позвонишь? Работнику, или автобусу, который его привезёт? Или в офис, что-бы его там в офисе сами искали? Очевидно, если ты всех работников хочешь собрать, и у тебя их много, то ты не станешь звонить каждому, а позвонишь в офис, пусть там их ищут и собирают. Тоже самое и с точкой - она слишком незначительна, что-бы ей лично слать сообщение. Потому точки обычно являются частью более общего объекта, например полигона, к которому и обращаются, со всеме вышеперечисленными целями.

Ну почему же нельзя?

template<class TArray,>
TArray::const_reference last(const TArray &array)
{
    if (array.size() == 0)
        throw std::runtime_error("array is empty");
    return array[array.size() - 1];
}

м... и причём тут «утиная типизация»?

И да, смысл «нельзя» в том, что несмотря на то, что оно и компиллится, но это быдлокод. ИМХО. Во всяком случае в C++.

STL и темболее iostream настолько низкоуровневое

Жжошь чо, пеши еще :)

нельзя делать невиртуальные деструкторы

Вообще-то можно, если не используешь виртуальные функции, а например, хватает CRTP :)

Пургу несешь местами :)

м... и причём тут «утиная типизация»?

При том, что требования к TArray: наличие функции size и оператора []. Только тут эти требования будут проверены при компиляции.

И да, смысл «нельзя» в том, что несмотря на то, что оно и компиллится, но это быдлокод

Обобщённый код - это быдлокод?

Определенная практическая польза C++ в мультипарадигменности :) Никто не обязывает пользоваться ООП. И использование ООП нихрена не привязано к экономии денег :)

Жжошь чо, пеши еще :)

с т.з. ООП - низкоуровневое. Нормальная задачка для ООП, это например окошко GUI, с кучей разных свойств и методов. И с кучей похожих (но других) окошек. А для потока/файла достаточно тривиальной структуры FILE и десятка функций из glibc. Делать для этого ООП обёртку ИМХО изврат.

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

а я могу в С++ написать

log << «%8.3f\n» << foo;

или

log %«8.3f\n» << bar << " blah blah " %«8.3f\n» << foo;

и твоя «аргументация» идет лесом :) Опять же «экономия букаф» не означает автоматически экономии кода или какой-то там сферической в вакууме «оптимизации». Разговоры о «костыльности» - пурга без обоснований профита.

Вообще-то можно

делай, я разрешаю. А я - не буду.

если не используешь виртуальные функции, а например, хватает CRTP

и при чём тут ООП?

Не изврат, а вопрос удобства. Иначе кодили б щас GUI макросами на асме.

При том, что требования к TArray: наличие функции size и оператора []. Только тут эти требования будут проверены при компиляции.

ИМХО это немного не то.

Обобщённый код - это быдлокод?

нет. Обобщённый код - на то и обобщённый код, что он обобщённый. Напротив, конкретный код должен быть конкретным. К.О. Однако, пишем-то мы IRL конкретный код? Вот и получается, что «обобщённый код» в реальном проекте == сферический конь в вакууме. Во всяком случае, в рамках C++.

Никто не обязывает пользоваться ООП. И использование ООП нихрена не привязано к экономии денег

у тебя - не привязано, а мне так проще => быстрее => приносит больше профита.

Не при чем. Просто использование ООП - не какая-то насущная необходимость в С++ (как и «запрет» на невиртуальные деструкторы зависит лишь от использования виртуальных методов, что не есть обязательно). Парадигма под задачу, а не задача под парадигму.