Стандарт C++

[MrD]

dikun писал(а):

Когда я начинал программировать на Java, то были актуальны следующие проблемы:

• ну, отсутствие структуры (struct) в Джаве как удобного для определённых целей частного случая класса мы переживём ;
• всякие мелочи, типа запрета на определение метода вне класса или требования принадлежности любой функции к классу мы не будем упоминать;
• не поддерживается множественное наследование, исключение (до известной степени) - интерфейсы;
• забавно смотрится предложение Swing'а испольсовать в некоторых случаях адаптер для реализации слушателя (из-за понятных ограничений языка), даже если мне нужно всего лишь один метод вызвать;
• нет шаблонов (templates).

Как у Джавы сейчас с этим?

1. С точки зрения набора текста описание структуры и класса без методов отличаются одним словом. Кстати, в C++ класс отличается от структуры только реализацией механизма наследования и возможностью введения ( ) абстрактных членов, использование структур лишь облегчает работу оптимизатора.

2. Запрет на определение метода вне класса, отсутствие глобальных переменных, и т.д. означает, что Java действительно язык ООП, а не гибрид. Это не недостаток, а достоинство.

3. Запрет на множественное наследование - единственный известный мне 100% способ обеспечить однозначность понимания синтаксически правильного кода программы. Если вы пользователь - вам плевать на эту однозначность, а для разработчиков компиляторов множественное наследование - неразрешимая проблема. В результате каждым разработчиком принимается свое паллиативное решение, таким образом, результат компиляции - непредсказуем в общем случае.

4. Не понимаю о чем речь...

5. Все интегрированные среды, с которыми я работал (NetBeans, Sun Java Studio Creator/Enterprise, JBuilder), имеют неплохие дизайнеры для десктопных задач и набор шаблонов на все случаи жизни - апплет, сервлет, интерпрайс джава бинс ...

[Dims]

dikun писал(а):

Когда я начинал программировать на Java, то были актуальны следующие проблемы:

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

Прокомментирую по пунктам.

Цитата:

[*]ну, отсутствие структуры (struct) в Джаве как удобного для определённых целей частного случая класса мы переживём ;

В Си++ структура ничем не отличается от класса кроме того, что в ней все члены по умолчанию публичные. Пожалуйста, в джаве тоже можно сделать класс, у которого все члены публичные.

Цитата:

[*]всякие мелочи, типа запрета на определение метода вне класса или требования принадлежности любой функции к классу мы не будем упоминать;

Ничего не мешает отпределить класс с одной статической функцией. Но это желание обычно говорит о неполноте объектного подхода. Наверняка у вас несколько таких функций -- определите их в класс "утилиты" например.

Цитата:

[*]не поддерживается множественное наследование, исключение (до известной степени) - интерфейсы;

Не не поддерживается, а намеренно запрещено. В Си++ это приводило к идеологическим глюкам. Например, если два класса являются наследниками одного, а потом оба порождают третий, то должен ли самый базовый класс входит в него дважды?

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

Цитата:

[*]нет шаблонов (templates).

Тоже правильно. Вы должны написать функции или класс, определённые для надкласса. А потом передавать ему экземпляры подкласса. Это будет то же самое, что и шаблоны.

[незваный гость]

MrD писал(а):

2. Запрет на определение метода вне класса, отсутствие глобальных переменных, и т.д. означает, что Java действительно язык ООП, а не гибрид. Это не недостаток, а достоинство.

В свое время было модно делать алгоритмические языки. А выжили языки программирования -- некрасивые, несистематичные, с избыточностью конструкций, зато удобные в использовании. Мне лично не нужен язык ОО программирования, тем более что ОО программирование imho оксиморон. Мне нужен язык программирования, поддерживающий ОО анализ и ОО проектирование. Простая ситуация -- мне нужен метод, создающий экземпляры класса. Какого хрена его запихивать в класс? Он принадлежит (уж коли принадлежит) металассу. Но в Жабе нет метаклассов (они есть в Smalltalk'е). И начинаем мешать сущности... Не люблю я языковой снобизм, что хошь со мной делай.

MrD писал(а):

3. Запрет на множественное наследование - единственный известный мне 100% способ обеспечить однозначность понимания синтаксически правильного кода программы. Если вы пользователь - вам плевать на эту однозначность, а для разработчиков компиляторов множественное наследование - неразрешимая проблема. В результате каждым разработчиком принимается свое паллиативное решение, таким образом, результат компиляции - непредсказуем в общем случае.

"""Вы будете долго смеяться, но""" эта проблема успешно решена. Почитайте The Python 2.3 Method Resolution Order. Метод, однако, не оригинален -- он был разработан в 1996 для Dylan.

[MrD]

незванный гость писал(а):

MrD писал(а):

3. Запрет на множественное наследование - единственный известный мне 100% способ обеспечить однозначность понимания синтаксически правильного кода программы. Если вы пользователь - вам плевать на эту однозначность, а для разработчиков компиляторов множественное наследование - неразрешимая проблема. В результате каждым разработчиком принимается свое паллиативное решение, таким образом, результат компиляции - непредсказуем в общем случае.

"""Вы будете долго смеяться, но""" эта проблема успешно решена. Почитайте The Python 2.3 Method Resolution Order. Метод, однако, не оригинален -- он был разработан в 1996 для Dylan.

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

1. Как много времени программист будет выяснять к члену какого базового класса он сейчас обращается при более-менее сложной иерархии? Как будут чувствовать себя его коллеги по команде?

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

Решение проблемы и теоретическое решение проблемы – разные вещи. Решение должно быть удобным в использовании.

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

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

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

[незваный гость]

MrD писал(а):

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

Простите, но Вы поняли неправильно. С3 алгоритм используется и будет использоваться в обозримом будущем.

Что же касается остальных Ваших риторических вопросов, то должен сказать, что я не придерживаюсь Вашего желания диктовать всем, как они должны программировать. Хотя и имею опыт командной работы, разработки больших систем et cetera. Множественное наследование связано со определенным свойством мира, в котором мы живем, и который программная система лишь отражает. А именно, каждый выступает в мире во множестве ролей (отец, сын, муж, любовник, начальник, подчиненный, ...). У некоторых из них есть общие черты... И выписывать комбинаторное множество интерфейсов как минимум не очень удобно. Гораздо проще выписать ролевое поведение, а потом объявить, что Вася -- суть совокупность этих ролей. С интерфейсами этот номер не проходит.

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

[Yuri Gendelman]

незванный гость писал(а):

Простая ситуация -- мне нужен метод, создающий экземпляры класса. Какого хрена его запихивать в класс?

Я делаю этот метод static методом того самого класса, экземпляр которого создается. Мне кажется, там ему и место.

[MrD]

незванный гость писал(а):

MrD писал(а):

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

Простите, но Вы поняли неправильно. С3 алгоритм используется и будет использоваться в обозримом будущем.

Как тогда понимать цитату из предложенного документа:

"Python 2.3 raises an exception in this situation (TypeError: MRO conflict among bases Y, X) forbidding the naive programmer from creating ambiguous hierarchies. Python 2.2 instead does not raise an exception, but chooses an ad hoc ordering (CABXYO in this case)."

[незваный гость]

Буквально. Python запрещает двусмысленные иерархии, для которых порядок наследования не может быть линеаризован. Но не все иерархии.

Мне больше нравиться ограничение Python'а, чем Java. Но это дело вкуса.

[незваный гость]

Yuri Gendelman писал(а):

незванный гость писал(а):

Простая ситуация -- мне нужен метод, создающий экземпляры класса. Какого хрена его запихивать в класс?

Я делаю этот метод static методом того самого класса, экземпляр которого создается. Мне кажется, там ему и место.

Я знаю о наличии static меотдов. Я просто не согласен идеологически с их привязыванием к классу. Технически именно так я обычно и поступаю, или создаю отдельный класс ObjectFаctory.

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

Вообще говоря, ригористам объектного программирования можно было бы создать супер-объект "среда", в котором и описываются все классы и методы. Ничего противоестественного в этом нет, ка нет ничего противоестественного в рассмотрении чисел как объектов (правда, это не практично).

Коли уж зашла речь о парадигме объектов, кто-нибудь может мне объяснить высокий смысл определения в объекте бинарных операций типа "+" (в С++)? Я по простоте душевной считал плюс унарной операцией, применяемой к упорядоченной паре (что вполне соответствует математической трактовке). Определение бинарной операции как операции на паре посвящена глава в Exceptional C++ Sutter'а.

[Yuri Gendelman]

незванный гость писал(а):

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

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

незванный гость писал(а):

...кто-нибудь может мне объяснить высокий смысл определения в объекте бинарных операций типа "+" (в С++)? Я по простоте душевной считал плюс унарной операцией, применяемой к упорядоченной паре (что вполне соответствует математической трактовке).

Только не говорите, что не слышали в курсе высшей алгебры про бинарные операции.
Я как-то встретил вопрос (простодушного ?) программиста, который недоумевал по поводу "странной" формулы
a = b (mod c).

[незваный гость]

Yuri Gendelman писал(а):

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

Можно считать и так. Я не уверен, однако, что производитель -- необходимо часть метакласса. И, сообственно говоря, производитель -- это пример. "Брак" есть операция над парой объектов "женщина" и "мужчина" (если Вы не живете в Массачусетсе, конечно). Запихивать его ни в "женщину", ни в "мужчину" не логично. Если Вам кажется, что "брак" порождает новый объект "семья", к классу которого "брак" и должен принадлежать, замените "брак" на "соитие", ничего не порождающее. Я готов согласится, что мы всегда можем расширить понятийно-классовую систему до охватывающей нужноые нам объекты и операции, но мне, ничтожному, кажется, что это размножение классов без надобности. Во славу ОО принципа.

Видите ли, я не против Java per se. Я уважаю этот язык, и пользуюсь им с удовольствием, когда подворачивается работа. Я против обожествеления принципа, принципов ради принципов. Я очень сомневаюсь, что эта идея "все -- в классе" эволюционно победит. Я не вижу преимуществ, ни концептуальных, ни реализационных, и вижу концептуальные недостатки. Я не люблю языковой снобизм, как я уже говорил. Излишняя ориентация на любую парадигму, будь то функциональное программирование, или "объектное программировние" мне претит. Я предпочитаю свободу грамотно писать программу.

Yuri Gendelman писал(а):

незванный гость писал(а):

...кто-нибудь может мне объяснить высокий смысл определения в объекте бинарных операций типа "+" (в С++)? Я по простоте душевной считал плюс унарной операцией, применяемой к упорядоченной паре (что вполне соответствует математической трактовке).

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

Не буду. Поскольку бинарная операция (de jure) определяется как $f: X \times X \rightarrow X$. Что есть функция на множестве упорядоченных пар (сие есть определение декартова произведения, коли я не ошибаюсь). Бинарная операция -- удобная свертка длинной формулы. На самом деле, 4.plus(3) a la Smalltalk создает немалые трудности и в определении объектов, и в написании програм (замечу, ядовито, что читается это как "к четырем прибавить три", то есть слабо подразумевая изменение объекта четыре). Я бы сказал, (4, 3).plus() в гораздо большей степени соответсвует семантике групповой операции (что встречается в языках типа Forth и в языках, не претендующих на чистый ОО. Читается, естественно, как "сумма четырех и трех"). Но это дело вкуса (быть может).

[Dims]

незванный гость писал(а):

Простая ситуация -- мне нужен метод, создающий экземпляры класса. Какого хрена его запихивать в класс?

А почему бы и нет? Можно даже запихнуть его в тот класс, который он делает. Получится ещё один конструктор. Почему конструктор должен быть где-то ещё?

Цитата:

Он принадлежит (уж коли принадлежит) металассу. Но в Жабе нет метаклассов

А какая польза от такого деления?

[Dims]

незванный гость писал(а):

Коли уж зашла речь о парадигме объектов, кто-нибудь может мне объяснить высокий смысл определения в объекте бинарных операций типа "+" (в С++)?

Это просто синтаксическое сокращение.

Цитата:

Я по простоте душевной считал плюс унарной операцией, применяемой к упорядоченной паре (что вполне соответствует математической трактовке).

Тогда надо было бы придумать синтаксис, как быстренько слепить налету класс-пару, придумать, как проверка типов должна регировать на это (например, пара целых и пара векторов -- это один тип?).

По-момему, этого красиво не сделали ещё нигде.

[Dims]

незванный гость писал(а):

Видите ли, я не против Java per se. Я уважаю этот язык, и пользуюсь им с удовольствием, когда подворачивается работа. Я против обожествеления принципа, принципов ради принципов.

Тут дело не в обожествлении. Объектно можно писать и на простом Си. А на объектном языке можно писать не объектно. Тут дело в том, что язык ТОЛКАЕТ к определённым правилам программирования и удерживает программиста в них, как в колее. Это служит цели избавления от ошибок, не более.

Полную "свободу" даёт ассемблер. Но он же и наиболее "ошибкогенный".

Допустим, мы сделали абсолютный язык, который допускает программирование в любой парадигме. То есть, можно там писать и объектно и функционально и реляционно и не знаю-ещё-как.

Тогда разумно было бы ввести в этот язык оператор paradygm (?) который бы фиксировал дальнейшую парадигму и не допускал отклонений от неё. Этот оператор был бы полностью аналогичен по роли оператору int i в современном Си, который не допускает класть в переменныю i вещественных чисел.

Иными словами, чем полнее в языке воплощена парадигма (любая), тем он более защищён от ошибок. Это не обожествление, это утилитарный принцип.

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

[незваный гость]

Dims писал(а):

Цитата:

Я по простоте душевной считал плюс унарной операцией, применяемой к упорядоченной паре (что вполне соответствует математической трактовке).

Тогда надо было бы придумать синтаксис, как быстренько слепить налету класс-пару, придумать, как проверка типов должна регировать на это (например, пара целых и пара векторов -- это один тип?).

По-момему, этого красиво не сделали ещё нигде.

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

Интересно, что пре-ОО языки, не имея объектов, интерпретировли бинарные операции традиционным способом.