RE:

А какое отношение Страуструп имеет к объектно-ориентированному программированию? Это функция main и глобальные переменные объектно ориентируют?

Понимаю еще бы это был создатель Симулы или Смалтока (ну или Геслинг на худой конец) ...

А что C++ уже перестал бить объектно-ориентированным?

> А какое отношение Страуструп имеет к объектно-ориентированному программированию?

Самое что ни на есть непосредственное.

> Это функция main и глобальные переменные объектно ориентируют?

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

> Понимаю еще бы это был создатель Симулы или Смалтока (ну или Геслинг на худой конец) ...

Да, Симула и Смалток конечно навороченные ООП-языки...:) А ты на них писал? Много? И начем ты щас пишешь? Просвети, кто такой Геслинг. И если ты такой поборник чистых ООП, то почему Eiffel забыл упомянуть (сорри, точного названия не помню - больно уж часто сталкивался с его реализациями, прям на каждом шагу...)?

Spectr

А это только у меня следующие страницы не открываются?

>Да, если в языке определена точка запуска программы, то это отстойный язык, совершенно с тобой согласен :)

А можно, пожалуйста, пояснить, почему именно? Это не подколки, я просто пока что несильно разбираюсь в этих вопросах...

RE:

>Глобальные переменные вообще-то для совместимости с С используются
Ну и в чем тогда объектная-ориентируемость? :)
Плюсовым компилятором можно скомпилировать программу на C, где тут ориентируемость? :)

Так что объектность может и есть, а ориентируемости нет как нет. :)

>А ты на них писал?
На Java и Smalltalk - да.

>И если ты такой поборник чистых ООП, то почему Eiffel забыл упомянуть
Дык я же не спец... :) Я еще с десяток наверняка не знаю ;)

А он когда-нибудь был?

> А можно, пожалуйста, пояснить, почему именно?

Та не, это просто я прикалываюсь над теми людьми, которые говорят, что если есть функция main, то это - признак "плохого стиля ООП". На самом деле я не совсем понимаю, чем это плохо, и не представляю себе, в чем преимущества возможности запуска класса самого по себе - ведь программа - не собрание разрозненных классов. Я лично всегда в функции main создаю объект класса, и запускаю его метод, который и выполняет всю программу - и не вижу ничего в этом плохого:)

Spectr

RE:

Spectr: не столько main, сколько вообще понятие глобальных функций и переменных из C.

Нет идеологии - есть мешанина

> Плюсовым компилятором можно скомпилировать программу на C, где тут ориентируемость? :)

Ага, а кухонным ножиком можно человека зарезать - но ведь это не его основная функция:)

> Так что объектность может и есть, а ориентируемости нет как нет. :)

Не-а, соглассно классификации, Simula (если не ошибаюсь) - объектный язык, но не ОО. Где-то есть, не помню, давно уже читал, формальное определение, что такое объектные языки, а что - объектно-ориентированные:)

Spectr

RE:

Spectr:
>Simula (если не ошибаюсь) - объектный язык, но не ОО
А он не тот и не другой. Просто он - это начало всего :)

2Murr: <<Ну и в чем тогда объектная-ориентируемость? >>

1) инкапсуляция

2) наследование

3) полиморфизм.

Есть возражения?

RE:

>Есть возражения?
Расплывчатая формулировка...

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

Ну, глобальные переменные - вешь действительно печальная, но что делать, если используешь С-библиотеку, где они используются, например?

> Нет идеологии - есть мешанина

А вот для понимания идеологии стоит почитать к примеру книгу тогоже Бьярни "Дизайн и эволюция языка C++". Мешанина - не совсем, разные возможности используются для разных целей, и в C++ никто не навязывает определенного стиля - используй, какой тебе больше подходит для твоих задач. Я например не разу не использовал RTTI, и до исключений в реальных проектах руки пока не дошли - но это же не значит, что кто-то их не использует, или что их наличие в языке требует использовать их повсюду:)

Ызусек

2Murr: <<Расплывчатая формулировка...>> Приведите свою версию (если общепринятая для Вас слишком "расплывчата")

> Расплывчатая формулировка...

А вот согласно шаблонам проектирования, лучше применять не наследование, а композицию - и это тоже объектно-ориентированный подход - так что же, это противоречие? :) Другие школы учат наследовать где только можно (В Smalltak'e например без этого сложно:)

Spectr

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

> Ты думаешь, он знает, что такое шаблоны проектирования???

Ну, он говорил, что не специалист, так мож заинтересуется:)

>А вот согласно шаблонам проектирования, лучше применять не наследование, а композицию - и это тоже объектно-ориентированный подход - так что же, это противоречие? :) Другие школы учат наследовать где только можно (В Smalltak'e например без этого сложно:)

Сейчас плавно перейдем к обсуждению COM и CORBA и наступит всеобщий объектно-ориентированный облом :))

> к обсуждению COM и CORBA

А при чем тут они? :) К тому же для COM родной язык - C :)

?

А кто спорит. С - вообще отец всех народов. ;)

>Murr (*) (14.10.2003 15:34:08) >Так что объектность может и есть, а ориентируемости нет как нет. :) Так ты вобще далек от этото дела, и какого же х.ра лезешь судить??? Объектные - это языки ПОЛНОСТЬЮ придерживающиеся общектной модели Объектно-ориентируемые - язики это по сути гибрид объектного и процедурного языков

>>И если ты такой поборник чистых ООП, то почему Eiffel забыл упомянуть >Дык я же не спец... :) Я еще с десяток наверняка не знаю ;)

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

>1) инкапсуляция

>2) наследование

>3) полиморфизм.

>Есть возражения?

Конечно. Проще всего отослать к Г. Бучу. У него только основных признаков 5. Например у тебя отсутсвует обязательнешее требование - иметь возможно однозначно идентифицировать объект (разница между "такой же" объект и "тот же самый" объект)

Сложнее,но полезнее послать смотреть CLOS (или его реализацию для guile'а - GOOPS - Благо, что есть в каждом дистрибутиве).

А то что ты назвал, это "ОО, как его понял Бъёрн Страуструп и фирма Борланд". Не больше. ...кстати даже в VisualBasic'е или, точнее, в COM'модели уже появляются и агрегатирование и метаклассы.

А в Zope'е есть ещё и заимствование...

>> к обсуждению COM и CORBA

>А при чем тут они? :)

Там нет наследования. Что не мешает им быть объектными моделями. Хотя есть иерархия (а следовательно, они ещё и "ориентированные").

>К тому же для COM родной язык - C :)

Бред

> Там нет наследования. Что не мешает им быть объектными моделями. > Бред

Обоснуй. Объектные программы спокойно можно писать и на C, для этого не надо каких-то сильных напряжений.

> а следовательно, они ещё и "ориентированные"

Сам себе противоречишь - говоришь, что нет наследования, а при этом говоришь, что они "ориентированные". Объектные и объектно-ориентированные - разные вещи, не стоит путать.

МДаааааа.......

Надо ссылку на этот тред на кокой небудь www.CUJ.com послать, То-то там посмеются над сумашедшими русскими которые для себя открыли что С++ не обектно ориентированый. Последние два месяца на лоре что не обсуждение то открытие щедро сдобренное лозунгами про шлаку

Осень однако...........

> щедро сдобренное лозунгами про шлаку

странно, а разве под слаку никто не пишет на C++? что-то тут про неё не вспоминали:)

2Murr

>Нет идеологии - есть мешанина

Это и есть идеология

C++ это - ГИБРИДНЫЙ язык

именно поэтому с такой легкостью он слелал почти все "единственно правильные" и "чистые" языки.

несмотря на его "некошерность" и "кривость" с теоретических точек зрения.

> несмотря на его "некошерность" и "кривость" с теоретических точек зрения.

5 баллов :))))

2Spectr (*) (14.10.2003 17:54:26)

Не поминай всуе Бога своего.

> всуе

чего-чего с ним не делать? :) ну, у кого какой Бог :) А вообще, лучше не стоит наверно, а то действительно, и на этот трейд придет ... (бог который) :)

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

>Обоснуй. Объектные программы спокойно можно писать и на C, для этого не >надо каких-то сильных напряжений.
Чего? Пример можно? Только ОБЯЗАТЕЛЬНО на C

>Обоснуй. Объектные программы спокойно можно писать и на C, для этого не надо каких-то сильных напряжений.

>Чего? Пример можно? Только ОБЯЗАТЕЛЬНО на C

Удивлен? ;)... кури исходники GTK+ :)...

Более того. "Объектные программы спокойно можно писать" даже и на С++. Трудно, неудобно, но возможно - пример http://www.openip.org/oa_overview.html.

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

прикольно у тебя получается. В принципе шуруп тоже можно инсталлировать молотком(или, с другой стороны, даже микроскопом), но тогда он будет чуть хуже держатся, а применяемый инструмент плохо совместим с материалом. Если ты не в состоянии использовать возможности ООП в С++, а используешь С++ как _еще один_ компилятор С, то как ты можешь говорить о объекро-ориентированности С++? Тут более уместны вопросы правильности выбора того или иного языка для тех или иных задач.

>> Бред

>Обоснуй. Объектные программы спокойно можно писать и на C

У COM'а нет "родного языка". Это спецификация.

Какой "родной" язык у SMTP?

>> а следовательно, они ещё и "ориентированные" >Сам себе противоречишь - говоришь, что нет наследования, а при этом говоришь, что они "ориентированные".

агрегатирование

Можно еще покурить исходники XFree, они больше ;)

То что для COM родной язык C - САБЖ мягко сказано, в этом полностью согласный. Хоть на асемблере педалируй, главное чтобы спецификации соблюдались. А вот термин "агрегатирование" - пардон коллега впервые слыщу. Может "Агрегирование".

> Только ОБЯЗАТЕЛЬНО на C

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

struct A{ int x; int y; }; int x A_get_x(A *this); void A_set_x(A *this, int _x);

- в результате имеем класс А с методами get_x, set_x. Перегрузка функций реализуется кодированием в имени типов аргументов... Лучше возьми и почитай тогда книгу о том, как работает компилятор на низком уровне. Просто С++ компилятор делает все это за тебя, но это не значит, что это же на С нельзя написать, но это потребует больших усилий.

Страуструп открыл для себя понятие инварианта. ;) Интересно, стОит ли в следующией версии языка ждать появления слов promise() и ensure() наряду с автоматическим сохранением состояния объекта на момент получения сообщения для отката? ;)

>А вот термин "агрегатирование" - пардон коллега впервые слыщу. Может "Агрегирование".

Может. Давно это всё было.

> наряду с автоматическим сохранением состояния объекта на момент получения сообщения для отката? ;)

Навряд ли - опять будет библиотекой реализовано ;)

nebolshoe zamechanie

to Spectr( otnositelno ruchnoj realizacii interfeisnyh funkcij, takih kak get,set na C primenitelno k strukturam ): Eto _tebe_, kak avtoru etogo 'klassa' budet poniatno kak ispolzovat' etot 'klass', a dlia _drugih_ uchastnikov proekta eto budet 'vozmozhnost na vybor'. C++ kompiliator s primeneniem private _garantiruet_ chto obrashenie k peremennym klassa budet osuchestvlenno _tol'ko_ cherez interfeisnye funkcii. U 'loha' Straustruppa eto nazyvaetsia _modul'nost'_. ;)

P.S. Sorry za translit

ну, просили на чистом С - вот и привел. Да, яркий пример - это GTK. А насчет защищенных членов - так эта проверка происходит в процессе компиляции, и если ты получишь каким-то образом указатель или ссылку на private, protected член, то никто ничего тебе гарантировать не будет. :) Т.е. это не проверка времени выполнения, а компиляции:) А насчет модульности - так Бьярни это называет не модулем(класс), а элементом защиты.

Если уж зашел про это разговор, то первые версии CFront просто транслировали код C++ в код на C. Точно также себя ведет и компилятор Sather'а...

> Spectr: "Навряд ли - опять будет библиотекой реализовано ;)"

заколебутся реализовывать. =) ensure() это элемент формальной спецификации типа, который, грубо говоря, позволяет обеспечить гарантированную и автоматическую проверку инварианта _после_ отработки метода (в терминологии с++, сразу после выполения функцией return). как в Eiffel. ;)

ксати, размышления Страуструпа в статье о классе Date, наводят еще на одну мысль: возможно, у с++ есть-таки шанс получить нормальную поддержку модулей. =)

"Может, стоило реанимировать понятие о функциях call и return в подражание методам :befor и :after, имеющимя в языке CLOS, но пользователи и так жалуются на сложности механизмов множественного наследования." в первой реализации C with Classes были call и return, но потом их убрали. Будут ли они опять? Наврядли, если этот вопрос уже поднимали.

А насчет модулей - так есть namespace, которая решает эту проблему :)

> Spectr: "Может, стоило реанимировать понятие о функциях..."

нет, -- сразу в морг. =) promise/require и ensure это не совсем функции. это элементы формальной спецификации соглашения. вот как выглядит "инклуд" на Eiffel:
http://pauillac.inria.fr/cdrom/www/SmallEiffel/libraries/classes/integer.html . В применении к множественному наследованию, они помогают избежать бардака. Хотя, я не говорю, что из С++ надо сделать Eiffel, но раз уж речь зашла об инвариантах...

> А насчет модулей - так есть namespace, которая решает эту проблему :)

какую проблему? =) нормальные модули это не только namespace.