А можно подробнее?



За что купил, за то и продал.  

Полностью ОО - программа без извращений  

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

Добавлено @ 18:48 
Я вообще не понимаю разговоров о "некроссплатформенности" Java. Один из аргументов - разница в наборе классов RT; другой - разные JVM, на которых один и тот же код может выполняться по-разному; третий - не везде есть JVM. Все эти утверждения несостоятельны: байт-код исполняется одинаково везде. Если в в JVM для утюга отсутствуют классы для работы с дисплеем или в какой-то реализации JVM попросту наделано ошибок, то это никак не относится к вопросу о кроссплатформенности. Если для платформы X нет JVM - никто не мешает её написать. 

В таком случае напишите пожалуйста полностью ООПрограмму на С++ (Ну или "более" ООПрограмму) 


Добавлю, что кроссплатформенность заканчивается там, где заканчиваются платтформы, на которые разработчику следует ориентироваться. А нормальные JVM есть для линя, винды, соляриса. Это наверняка покрывает бОльшую часть необходимых.
   

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

Для java: перенос с платформы на платформу без изменений. 

Перенос чего? Кода? Бинарника? Проекта? 

Не честно
Это множественное наследование… в Java оно реализуется(частично) через implements… а вообще по Эккелю Java более чистокровный ОО язык.
И еще, на Java можно реализовать аспектно-орентированный подход в программировании, в C++ это сделать трудней… 

Разумеется, конечного программного продукта. Бинарника, то бишь.

Добавлено @ 20:20 

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

Чистокровный? Ну уж ерунды-то не говорите. Да и кто такой Эккель? Это что за авторитет такой? 

Да, в C++ это делать несколько трудней, но ничто не мешает. 

[QUOTE=sergej.z,9.5.2006,  18:23]
Про ASM это ты ляпнул!  стоимость портирования ASM приложения на другую процессорную архитектуру равна как минимум стоимости разработки проекта с нуля  напиши прогу на асме и пропартируй на x86, Motorolla, Z80 и мой любый мэинфрейм DEC  - убедишся сам. В истории софта, самая-самая "много на ASM" система была Novell Netware 2.x. Они говрили что она написана на ASM на 30% (невероятно много!!! ). история помнит что установка этой OS, была настолько сложным делом что возникли 100-ни контор в этом помогающие... а дело в том что там было необходимо фактически компилировать OS под каждый конкретный сервер... 

Ну а про Java никто не спорит, да сравнительно очень просто, да экономит массу денег.Нo не то чтобы совсем без усилий и проблем.

Для меня "более" объектен тот язык который предоставляет мне больше эээ... ОО-возможностей. С++ есть множесетвенное наследование классов, перегрузка операций, шаблоны. да можно спорить о том хороший ли скажем стиль - активно применять множественное наследование в глубоких иерархиях и т.д и т.п. но эта возможность в С++ есть, а в java - нет. Есть масса примеров когда грамотное применение множественного наследования действительно порождает изящество и помогает избежать маштабного дублировнаия кода. множественное наследование интерфейсов и внутринние классы зглаживают, но не заменяют.

перегрузка операций это что-то отсутсвие чегов Java  меня злит постоянно.... я искренне не понимаю почему её не возможно реализовать хотябы на уровне компилятора. ээххх каждый раз  когда я работаю с JDBC вспоминаеться объектно орриентированная С++ библиотека для работы с сервером SQLBase... они перегрузили только 2 операции а 10-ки строк кода тупых сэтов и гетов просто ушли... 

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


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

И наконец третье важное отличие явы - конструкция finally {} после try, которая гарантированно выполняется независимо от того, были exceptions или нет.  Этот finally очень облегчает работу с ресурсами и уменьшает количество ошибок.

  

Это сообщение отредактировал(а) Бонифаций - 9.5.2006, 21:48

Что вы говорите? А как же быть с тем, что когда исключения появились в C++, Java была только в проекте?

Ничто не мешает реализовать GC в программе на C++. GC - это мимо кассы однозначно.   

Это сообщение отредактировал(а) w1nd - 9.5.2006, 21:48

Хм… ну в таком случаи нужно сравнивать С++ с С# там тоже убрали множественное наследование в чистом виде… C# это ж не отход от принципов ООП а, как предполагается, их развитие… 

ключевые слова "требует" и "позволяет" - тут есть разница.  

Если время дорого, имеет смысл подумать о применении фреймворков. И почему геты и сеты тупые? Это же часть технологии JavaBeans, играющей не последнюю роль в вышеупомянутых фреймворках (сериализация объектов в РБД и пр...)  

Это сообщение отредактировал(а) JUncle - 9.5.2006, 21:52