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

Не уводи обсуждение в сторону - против буферизации ещё никто не выступал.

Но-но-но. Ты сказал, что ООП для ввода/вывода ВООБЩЕ не нужно и бесполезно.

man simula

Ах да. Проверка ошибки чтения... Как ты сделаешь ее через scanf?

Расскажи давай. Потом когда расскажешь сравни с тем, как это делается в Си++ и почувствуй разницу.

Все трое не имеют прямого отношения к модели ООП.

GObject с GObjectIntrospection не имеют? Классы есть, наследование есть, сигналы есть. Про Java и Objective-C - это больше относительно их графических библиотек, которые вполне ОО.

А если не забывать, то нужно ещё вспомнить крякающе прототипное ООП ECMAScripta.

то скорее Erlang и микроядра

Конкурентность и распределённость шире чем ООП - в некоторых случаях похоже, но и только.

С каких пор объекты в C++ получили собственные методы? Походу ты и представление о С++ не имеешь...

что, думаешь у объектов в C++ нет методов? ВНЕЗАПНО: они там были изначально. Мало того, нестатические методы вообще смысла не имеют в отрыве от объектов. Без объекта можно использовать только статические методы, но мы не о них. Подучи матчасть пожалуйста.

Методы определяются для класса. Для конкретного объекта С++ их не определяет.

Инкапсуляция там есть. У нас есть методы работы с FILE - fopen/fgetc/fprintf/fscanf/fclose. Нам не нужно трогать struct FILE. Более того нам это не нужно! Вся работа с ним осуществляется через интерфейс. Доступ к полям FILE -это хак. Хаки мы не считаем за нормальное использование. FILE полностью защищен! Все возможные операции с ним доступны через интерфейсы. Пойми ты уже наконец, что инкапсуляция это не private/public. Ты не понимаешь ООП! А полиморфизм в данном случае, как и наследование не нужны.

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

Без объекта можно использовать только статические методы, но мы не о них.

Ну если говорить о Си++ то можно вполне себе вызвать.

((Object *) NULL).funct();

Дошли уже до того, что у нас FILE это ООП...

Это ты упоротый и не хочешь признать себя проигравшим.

А ostream::operator<<() это _как_ выводить?

Я уже говорил, что не ostream::operator<<, а operator<<(ostream&, T).

cout.operator<<()

RTFM.

 From: Alan Kay <alank@wdi.disney.com>
 Date: 1998-10-10 07:39:40 +0200
 To: squeak@cs.uiuc.edu
 Subject: Re: prototypes vs classes was: Re: Sun's HotSpot


 Folks --


 Just a gentle reminder that I took some pains at the last OOPSLA to try to
 remind everyone that Smalltalk is not only NOT its syntax or the class
 library, it is not even about classes. I'm sorry that I long ago coined the
 term "objects" for this topic because it gets many people to focus on the
 lesser idea.


 The big idea is "messaging" - that is what the kernal of Smalltalk/Squeak
 is all about ...

http://c2.com/cgi/wiki?AlanKayOnMessaging

А полиморфизм в данном случае, как и наследование не нужны.

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

Да? Тогда, походу, ты не знаешь что это значит.

а... Значит «drBatty не знает C++» отменяется, теперь выходит «drBatty знает C++, но не понимает!». Так?

Что мешает сделать свой метод, принимающий формат и ссылку на ostream?

ничего не мешает. Кроме того, что это будет уже не ostream и не ООП.

Фишка ООП в том и состоит, что fopen открывает _только_ FILE, а fclose закрывает _только_ его же. Если-бы FILE был классом, то мы могли-бы сделать свой FILE, причём fopen и fclose с ним-бы прекрасно работали. Но... Не судьба.

Не уводи обсуждение в сторону - против буферизации ещё никто не выступал.

Но-но-но. Ты сказал, что ООП для ввода/вывода ВООБЩЕ не нужно и бесполезно.

ООП нужно для буферизации?

ВООБЩЕ

вообще для ostream не нужно ООП. «ВООБЩЕ» это уж на лоре додумали...

ООП нужно для буферизации?

А для чего нужно не ООП? Чем оно лучше?=)

Ах да. Проверка ошибки чтения... Как ты сделаешь ее через scanf? Расскажи давай. Потом когда расскажешь сравни с тем, как это делается в Си++ и почувствуй разницу.

расскажи, как она сделана в istream, и в чём разница?

а... Значит «drBatty не знает C++» отменяется, теперь выходит «drBatty знает C++, но не понимает!». Так?

Там написано что «ты не знаешь», одно другому не мешает, но не суть. Смысл сводится к твоим словам, что operator<< не универсален, а применим только для cout. Это не так.

ничего не мешает. Кроме того, что это будет уже не ostream и не ООП.

ostream& T::out(ostream&, FormatType format);

Ты нам 3 день доказываешь, что для i/o ООП не нужно. Раз ты так упорен, то значит считаешь, что ВООБЩЕ. Или уже не считаешь?

Лучше ты напиши как она сделана и ощути разницу.

ООП нужно для буферизации?

Ты прикидываешься? То, что потоки могут выводить данные, в файл, в память, в никуда, сжимать, и т.д. ты просто исключаешь? В libc как минимум есть потоки для вывода в файл и в память.

Методы определяются для класса. Для конкретного объекта С++ их не определяет.

методы вызываются для объекта. Обычные методы без объекта не вызвать. Если ты не понял, мы сейчас обсуждаем вызов методов вроде cout.operator<<(), а не детали их определения.

вообще для ostream не нужно ООП. «ВООБЩЕ» это уж на лоре додумали.

да ладно

ostream_iterator<T>(ostream, delim);
copy(collection.begin(), collection.end(), ostream_iterator<int>(cout, "<>"));

Обычные методы без объекта не вызвать

вызвать-вызвать, статические методы вызываются для класса -)

Не, не, ключевой аспект ООП - динамический полиморфизм, а то мы так придём к тому, что шаблоны С++ - тоже ОО язык.

GObject ... Про Java и Objective-C - это больше относительно их графических библиотек

В этом смысле - да, вполне ОО. Но это не языки как таковые, а библиотеки, доступные из этих языков.

Я к тому, что нужно говорить о ostream, а не конкретно о cout.

cout.operator<<()

Нет такого оператора/метода. Есть T::operator<<(ostream&).

Инкапсуляция там есть. У нас есть методы работы с FILE - fopen/fgetc/fprintf/fscanf/fclose. Нам не нужно трогать struct FILE.

не нужно трогать

нам это не нужно!

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

Доступ к полям FILE -это хак. Хаки мы не считаем за нормальное использование. FILE полностью защищен!

это называется «защита на честном слове», клиент дал тебе своё честное-пионерское слово, что он не будет смотреть на твой FILE. НИКОГДА!!!11один-один (:

Самому не смешно?

Все возможные операции с ним доступны через интерфейсы.

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

Пойми ты уже наконец, что инкапсуляция это не private/public.

нет, это ты пойми. Я и так это знаю. private/protected это не инкапсуляция, это костыль, который в т.ч. обеспечивает инкапсуляцию.

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

наследование - тоже костыль, который реализует ООП в C. (и за счёт наследования, из C получается C++)

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

тогда расскажи нам, что твоё ООП утверждает?

можно вполне себе вызвать. ((Object *) NULL).funct();

может попробуешь?

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

Вот именно ты ничего не понимаешь в ООП просто. Инкапсуляция с private/public это средства языка организующие инкапсуляцию на уровне языка. Но это не есть сама суть инкапсуляции, это не инкапсуляция.

Попробую, и оно даже работает. Если метод funct не обращается к реальным полям объекта.

Я уже говорил, что не ostream::operator<<, а operator<<(ostream&, T).

какая разница, как operator<< перезагружать, в контексте нашего спора?

Самому не смешно?

При чем тут клиент? Тут есть программист. Который должен осознавать, что как надо или не надо делать. Использование полей структуры содержимое которой не документировано, а использование по доке возможно только через интерефейсы - это хак. Через хаки вообще можно очень многое сделать, ооочень многое. Но хак - это не нормальный способ работы. Хак это хак.

Есть T::operator<<(ostream&).

Ну как он будет использоваться? std::declval<T>() << std::declval<ostream>(), а надо, чтобы операнды были в обратном порядке.

А для чего нужно не ООП? Чем оно лучше?

время экономится. Выше я уже давал пример с коллекцией, которая без изменений может работать с новыми элементами. С FILE так не получается очевидно...

Там написано что «ты не знаешь», одно другому не мешает, но не суть. Смысл сводится к твоим словам, что operator<< не универсален, а применим только для cout. Это не так.

этот оператор применим только для ostream&, например для cout. И всё. Не для какого иного типа, кроме типа ostream& данный оператор не применим.

тогда расскажи нам, что твоё ООП утверждает?

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

Разница в том, что мой вариант расширяется для новых типов данных.

Ты мне лучше прямо сейчас напечатай обработку ошибок чтения из файла для ООП и для не ООП (scanf). Или уже сам осознал разницу? Тогда можно не печатать, да.

Ты нам 3 день доказываешь, что для i/o ООП не нужно. Раз ты так упорен, то значит считаешь, что ВООБЩЕ. Или уже не считаешь?

если ты ещё не понял, то повторяю: я считаю, что ООП ненужно для потоков i/o вроде iostream. Или скажем FILE. А вообще для i/o - ничего я не считаю, т.к. i/o бывает РАЗНОЕ, как и задачи.

Он применим для всех наследников ostream, о том и речь.

Ты прикидываешься? То, что потоки могут выводить данные, в файл, в память, в никуда, сжимать, и т.д. ты просто исключаешь? В libc как минимум есть потоки для вывода в файл и в память.

пусть они выводят что угодно, и _куда_ угодно. Вывод определённого типа данных никак к этому не относится. Особенно форматированный. Код, который выводит дробные числа должен знать, что это за числа, и как они представлены. Потому этот код должен быть прибит к этим дробным числам. А не к ostream, как вы здесь предлагаете. Именно по этой причине запись x->output() кошерная, а запись operator(ostream &cout, x) - некошерная.

А не к ostream, как вы здесь предлагаете

Врать перестань, внимательный ты наш.

вызвать-вызвать, статические методы вызываются для класса -)

выше уже сказано, что «обычные» в C++ являются НЕ статическими. Перед статическими ещё static писать надо. Так то.

Не суть. Главное что операцию определяет не ostream, а T.

Главное что операцию определяет не ostream, а T.

Тогда надо вынести оператор из класса T и при необходимости сделать его другом. Учитывая ADL, этот оператор будет частью интерфейса класса T.

Нет такого оператора/метода. Есть T::operator<<(ostream&).

учи матчасть. http://www.cplusplus.com/reference/iostream/ostream/operator<</

например ostream& operator<< (double val);

и да,

cout << 123;
cout.operator<<(123);

Только не надо акцентировать внимание на моей ошибке - важно что оператор для конкретного T определяется не в ostream, и что он работает для всех ostream а не только для cout.

(maybe you meant to use «->» ?)

а со стрелочкой да, твой хак работает. Вот только в данном случае объект всё равно есть - это разименованный NULL. Если его не трогать, то да, можно NULL разименовывать, только использовать его нельзя. Вызов метода в данном случае использованием не считается. Считай это фичей, а не багом, я разрешаю.

При чем тут клиент? Тут есть программист.

тут как минимум два программиста - один писал FILE и прочие fopen, а второй это использует. Вот второго я и назвал для краткости «клиентом».

Но хак - это не нормальный способ работы. Хак это хак.

Фишка ООП в том, что в нём не нужны подобные хаки. Благодаря полиморфизму всё и так работает. А благодаря инкапсуляции, не нужно задумываться о том, _как_ это всё получается. Главное - получается.