Java vs VC++ , нифига не понимаю.

Вообще, я на Джаве ни разу не программил. И даже не знаю, как она выглядит. И мне тут некоторые говорят, что типа изучать Джаву перспективно очень, так как она везде почти. Но я что-то сомневаюсь в этом =)
Так вот, если сравнить ее, эту самую Джаву с VC++, например, на чем программа будет быстрее, меньше и тд.
Хотелось бы послушать аргументы за и против =)

Батенька, на Жабе пишут не для того, что бы прога стала быстрее, а уж тем более - меньше

Цитата BugHunter @ 15.09.05, 13:04

Батенька, на Жабе пишут не для того, что бы прога стала быстрее, а уж тем более - меньше

Хорошо, тогда зачем на ней вообще пишут?

Цитата Dr_freeman @ 15.09.05, 13:29

Хорошо, тогда зачем на ней вообще пишут?

А это пусть тебе джависты объяснят.

Dr_freeman, на ней довольно быстро можно писать. Короче вот плюсы:
+ Высокая скорость разработки.
+ Удобная стандартная библиотека (Swing,..), что позволяет выполнить п. 1.
+ Кросс-платформенность.
+ Java устраняет часть типичных ошибок программиста (как то утечки памяти).

Но есть и минусы:
- Низкая скорость (язык все же интерпритируемый).
- Нужно наличие JRE.

Ну это конечно не полный список. Насчет возможностей языка - пожалуй тут почти все фичи из Си++ имеет и java

Цитата p_kolya @ 15.09.05, 13:34

Ну это конечно не полный список. Насчет возможностей языка - пожалуй тут почти все фичи из Си++ имеет и java

Ну, положим, далеко не все...

Flex Ferrum, ну каких возможностей нету в Java, которые есть в Си++?
Шаблоны? С 1.5 они есть и в джаве, там много чего есть...

Цитата p_kolya @ 15.09.05, 13:37

С 1.5 они есть и в джаве, там много чего есть...

Беглый поиск по java.sun.com дал нулевой результат. Либо я как-то не так искал, или что-то не то искал... Кинь ссылку. Желательно - на java.sun.com.

Цитата p_kolya @ 15.09.05, 13:37

ну каких возможностей нету в Java, которые есть в Си++?

То, что приводят в любой уважающей себя книге в первую очередь - указатели.

p_kolya - шаблоны в Жабе не компайл-тайм.
Нет операторов. Кто то это считает плюсом Жабы. Но не я.
Ну и ещё много чего
отсутсвие указателей, кстати, иногда записывают в + Жабе. Уж не знаю, можно ли это делать

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

Цитата trainer @ 15.09.05, 13:44

То, что приводят в любой уважающей себя книге в первую очередь - указатели.

Вах, trainer, какие указатели? Ты чего? Мы же стремимся к светлому будущему:

Цитата p_kolya @ 15.09.05, 13:34

устраняет часть типичных ошибок программиста (как то утечки памяти).

А ты про какие-то указатели говоришь. Интрузивный подсчет ссылок в корневом объекте + сборщик мусора + отсутствие стековых объектов - и никакие утечки памяти нам не страшны! Вперед товарисчи! Ура!

Цитата Dr_freeman @ 15.09.05, 13:47

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

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

Цитата Flex Ferrum @ 15.09.05, 13:48

Вах, trainer, какие указатели? Ты чего? Мы же стремимся к светлому будущему

Так я же не говорю, хорошо это или плохо. В C/C++ указатели есть? Есть. В Java есть? Нет. А хорошо это или плохо - это уже другой вопрос.

Цитата trainer @ 15.09.05, 13:54

Так я же не говорю, хорошо это или плохо. В C/C++ указатели есть? Есть. В Java есть? Нет. А хорошо это или плохо - это уже другой вопрос.

Тоже верно.

Цитата

Нет операторов. Кто то это считает плюсом Жабы. Но не я.

И не я. Запись одного выражения превращается в кошмар.

Цитата

В C/C++ указатели есть? Есть. В Java есть? Нет. А хорошо это или плохо - это уже другой вопрос.

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

Но почему-то думаю, что нечто такое хотя бы на уровне байт-кода существует...

Цитата BugHunter @ 15.09.05, 13:47

отсутсвие указателей, кстати, иногда записывают в + Жабе. Уж не знаю, можно ли это делать

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

Не понятно. Обе платформы дешёвые - а именно - бесплатные. Стоимость обучения и там и там немаленькая. Тогда о чём же ты? Может, это реплика из другого спора?

Цитата Flex Ferrum @ 15.09.05, 13:48

А ты про какие-то указатели говоришь. Интрузивный подсчет ссылок в корневом объекте + сборщик мусора + отсутствие стековых объектов - и никакие утечки памяти нам не страшны! Вперед товарисчи! Ура!

этого С++ не умеет, это надо писать самому.

нету операторов, шаблонов, указателй, функций НЕмемберов, конечного бинарника( хоть и есть обфускаторы, но код все равно можно восстановить в исходник) Хотя есть приложения для компиляции бинарников, но тут уже вопрос зачем тогда выбирали JAVA
отсутствие множественного наследования

зато есть уйма плюсов
можно начать
- авто сбор мусора (правда идет вразрез со статегией sentry из C++ )
- изначально потоково ориентированный язык, легко писать многопоточные приложения, легкая синхронизация потоков.
- легкая сереализируемость объектов
- встроенная поддержка сокетов
- наличие сильной криптографической фабрики непосредственно в SDK
- наличие делегатов (малый плюсик)
- наличие интерфейсныйх классов, как типа (малый плюсик)
- офигенная возможность генерить классы "на лету" из интерфейсных.
- мощное средство наподобии RTTI позволяющие оперировать классами.
- наличие финальных классов/методов

это еще не все
в общем если посмотреть на верхние плюсы ява, можно сразу убедиться, что она берет вверх над С++ в области создания клиент-серверных приложений, а орентированных на разные платфоры и подавно!
Конечно, многое в С++ лечиться библиотеками, НО это уже не чистый язык.

Цитата BugHunter @ 15.09.05, 14:20

Не понятно. Обе платформы дешёвые - а именно - бесплатные. Стоимость обучения и там и там немаленькая. Тогда о чём же ты? Может, это реплика из другого спора?

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

Добавлено 15.09.05, 14:26

Цитата Sazabis @ 15.09.05, 14:25

этого С++ не умеет, это надо писать самому.

А это относилось не к С++, а к джаве.

Добавлено 15.09.05, 14:28

Цитата Sazabis @ 15.09.05, 14:25

авто сбор мусора (правда идет вразрез со статегией sentry из C++ )
- изначально потоково ориентированный язык, легко писать многопоточные приложения, легкая синхронизация потоков.
- легкая сереализируемость объектов
- встроенная поддержка сокетов
- наличие сильной криптографической фабрики непосредственно в SDK
- наличие делегатов (малый плюсик)
- наличие интерфейсныйх классов, как типа (малый плюсик)
- офигенная возможность генерить классы "на лету" из интерфейсных.
- мощное средство наподобии RTTI позволяющие оперировать классами.
- наличие финальных классов/методов

Выкинь отсюда все, что не связано непосредственно с языком...

а stl из с++ тоже выкинуть ?

Цитата Sazabis @ 15.09.05, 14:33

а stl из с++ тоже выкинуть ?

Ну тады к С++ boost прибавь...

хорошо, даже если считать что boost не являеться частью С++, де факто эго можно считать частью языка. А теперь даже с бустом вместе выкинь что нибуть авто сбор мусора останеться даже с shared_ptr сериализация останеться даже с serialize. Делегатов можно убрать, но я бы оставил из-за (все-таки) кривой записи используя signal & bind

что выкинуть ?

Цитата

Сколько стоит обучение разработчика на С++

Дорого, очень и очень дорого.

Цитата BugHunter @ 15.09.05, 13:54

Это как раз очень удобно - мобильные платформы различаются значительно сильнее , чем PC, да и поболее их будет

Только каждый уважающий себя мобильник (неплохо звучит) поддерживает ПО на С, С++. И в своем большинстве, конкурентно способные игры пишутся на С. К тому же не стоит полагать, что GSM аппараты состовляют большую часть рынка. Хотя безусловно для этой части рынка Java - лучший выбор.

Цитата BugHunter @ 15.09.05, 14:52

Дорого, очень и очень дорого.

Вот то то и оно. И именно за счет нетривиальных фишек С++. Хотя, если сейчас массово сажать новичков на boost и stl - проблем должно быть меньше...

"Java is simple" - один из слоганов Sun. Это касается не только того, насколько его легко выучить. Это также касается того, насколько легко написать приложение, поддерживать и изменять.

Почему? Про сборщик мусора говорить не будем, хватит. Взглянем на кроссплатформенность. Это касается не только того, что скомпиленное приложение на Java не надо перекомпилировывать под другую платформу. Фигня, перекомпилить никогда не лень. Упрощение касается уже этапа разработки. Когда я думаю о реализации бизнес логики, я не хочу дополнительно думать о настоль низкоуровневых проблемах как "как сделать, чтобы на другой платформе не запутаться в файловой системе", "big endian vs little endian", "sizeof int == ?". Я знаю, что если это работает у меня, то это будет работать и там (с погрешностью на баги в разных VM и ОС).

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

Задача: создать distributed приложение, причем желательно сохранить гибкость в выборе конечных осей серверов. Сейчас клиент использует в основном NT-серваки, несколько Маков, но в течение следующих 2-х лет планирует пересесть на юниксы. Абсолютно не твержу, что это невозможно на сях. Но где будет больше ГЕММОРА?

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


Кроссплатформенность помогает также в создании веб приложений со сложным ГУИ, где HTML+JS - мало. Апплеты, хоть и несколько громоздкие, тут без преувеличения просто незаменимымы (Flash не предлагать, в диснейленд поедем в другой раз). А общение апплет-сервлет - также естественно. В этом случае о С/С++ уже просто речи нет.

Цитата Flex Ferrum @ 15.09.05, 13:48

Интрузивный подсчет ссылок в корневом объекте + сборщик мусора + отсутствие стековых объектов - и никакие утечки памяти нам не страшны! Вперед товарисчи! Ура!

"отсутствие стековых объектов" -- это как?

Вообще если уж переходить, то на C++/CLI имхо... Он и перспективнее (если под PC), и существенно поинтереснее жабы, хотя если под мобильники -- то без нее никуда, конечно. А скорость это дело десятое в большинстве случаев, к тому же, каких-то принципиальных причин проге, скомпиленной в байт-код работать медленее чем обычной, нативной -- нету. Может получиться даже совсем наоборот. Хотя реально сейчас оно действительно медленнее работает.

Цитата Ivan_Govnoff @ 15.09.05, 21:34

каких-то принципиальных причин проге, скомпиленной в байт-код работать медленее чем обычной, нативной -- нету

Еще как есть. И причина эта - трансляция байт-кода. Или это будет происходить неким волшебным образом?

Цитата Тайлер @ 15.09.05, 20:12

создать distributed приложение, причем желательно сохранить гибкость в выборе конечных осей серверов. Сейчас клиент использует в основном NT-серваки, несколько Маков, но в течение следующих 2-х лет планирует пересесть на юниксы. Абсолютно не твержу, что это невозможно на сях. Но где будет больше ГЕММОРА?

Qt предоставляет необходимую кроссплатформенность для С++, и геммороя не будет.

Цитата Ivan_Govnoff @ 15.09.05, 21:34

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

Уважаемый, ну и загнули же вы. Скорость очень важна, я по долгу службы активно пользую Zend Studio, который написан на яве, время отклика интерфейса достаточное, чтобы его заметить - мелоч, а раздражает. Про время запуска я умолчу,пока грузится ZS можно в буфет сбегать.

Так же могу вспомнить про старые версии PVCS, которые были написаны на Жабе. Такие тормоза!... Складывание в репозиторий, запрос по маске... всё это было крайне медленным. Они всё переписали на нормальном компилируемом языке. Стало значительно лучше (хотя, конечно, всё равно не идеально, но такова уж специфика - поиск по большим репозиториям никогда не был очень быстрым).

Цитата Ivan_Govnoff @ 15.09.05, 21:34

Цитата (Flex Ferrum @ Вчера, 17:48)
Интрузивный подсчет ссылок в корневом объекте + сборщик мусора + отсутствие стековых объектов - и никакие утечки памяти нам не страшны! Вперед товарисчи! Ура!

"отсутствие стековых объектов" -- это как?

Еще раз - я писал про джаву.

Добавлено 16.09.05, 06:33

Цитата Ivan_Govnoff @ 15.09.05, 21:34

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

Далеко не десятое. Именно за это и недолюбливаю проги на джаве - из за подтормаживания интерфейса. Да и GUI-компоненты у них рисуются по своему, а не нативно для платформы. Тоже, гм, несколько раздражает.

Цитата Flex Ferrum @ 16.09.05, 06:31

Да и GUI-компоненты у них рисуются по своему, а не нативно для платформы. Тоже, гм, несколько раздражает.

А ИМХО унифицированный вид интерфейса -- это плюс.

Цитата trainer @ 15.09.05, 21:51

Цитата Ivan_Govnoff @ 15.09.05, 21:34

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

Еще как есть. И причина эта - трансляция байт-кода. Или это будет происходить неким волшебным образом?

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

Цитата Antoxa1985 @ 15.09.05, 23:36

Уважаемый, ну и загнули же вы. Скорость очень важна, я по долгу службы активно пользую Zend Studio, который написан на яве, время отклика интерфейса достаточное, чтобы его заметить - мелоч, а раздражает. Про время запуска я умолчу,пока грузится ZS можно в буфет сбегать.

Цитата BugHunter @ 16.09.05, 04:17

Складывание в репозиторий, запрос по маске... всё это было крайне медленным.

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

Сообщение отредактировано: Ivan_Govnoff - 16.09.05, 07:11

Цитата Flex Ferrum @ 16.09.05, 06:31

Далеко не десятое. Именно за это и недолюбливаю проги на джаве - из за подтормаживания интерфейса. Да и GUI-компоненты у них рисуются по своему, а не нативно для платформы. Тоже, гм, несколько раздражает.

Для этого есть SWT. Глянь на тот же Azureus или Эклипс - там нативное ГУИ.

Цитата Antoxa1985 @ 15.09.05, 23:36

Qt предоставляет необходимую кроссплатформенность для С++, и геммороя не будет.

В этом примере ГУИ я имел ввиду на последнем месте.

Цитата Ivan_Govnoff @ 16.09.05, 07:11

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

Это почему? В чем принципиальное ограничение у традиционных компиляторов? Процессоры унифицированные, что такого может знать JIT-компилятор и не знать традиционный?

Цитата trainer @ 16.09.05, 08:22

что такого может знать JIT-компилятор и не знать традиционный?

Контекст исполнения?

Цитата trainer @ 16.09.05, 08:22

Это почему? В чем принципиальное ограничение у традиционных компиляторов? Процессоры унифицированные, что такого может знать JIT-компилятор и не знать традиционный?

Фишка в том, что JIT-компилятор -- это оптимизирующий компилятор и профайлер в одном флаконе. Он может сам определять hotspots в коде и оптимизировать их. Почитай вот эту замечательную статью, на меня она произвела сильное впечатление -- http://arstechnica.com/reviews/1q00/dynamo/dynamo-1.html.
Статья про эмулятор процессора HP PA-8000, работающем на таком же проце (а-ля vmWare), на котором программы работали быстрее, чем на самом PA-8000

Указатели в джаве не нужны. Там все объекты с которыми ты работаешь есть ссылки, за исключением примитовов. Потом в джаве не надо заботится при кросс-платформенном программирование о размере int'а напрмиер. Он всегда 4. Аналогично с другими типами.
Отсутсвие операторов действительно напрягает.

Цитата p_kolya @ 16.09.05, 09:24

Там все объекты с которыми ты работаешь есть ссылки,

причем ссылка эта может быть null

Цитата Тайлер @ 16.09.05, 08:31

Контекст исполнения?

Что именно в контексте исполнения?

Цитата Ivan_Govnoff @ 16.09.05, 08:34

на меня она произвела сильное впечатление -- http://arstechnica.com/reviews/1q00/dynamo/dynamo-1.html.

Ну да, восторженных слов там много, туманных объяснений тоже, только где все это, если это так шоколадно? Насколько я понимаю, предполагаемые преимущества базируются на ряде допущений. Ключевая фраза, на мой взгляд:

Цитата

Last week I attended a talk at MIT that underscored the increasing use of dynamic translation software as an interface between new processors and legacy binaries

Новые процессоры и (не оптимизированное под них) старое ПО.
Насколько я понял, информация об ускорении предоставлена самими создателями Dynamo. Хотелось бы увидеть независимых подтверждений. Да и я представляю требования к объему памяти.

Цитата trainer @ 16.09.05, 10:05

Что именно в контексте исполнения?

Цитата

In a JVM with dynamic compilation, a basic compiler translates Java methods the first time they are called. Later, a real-time profiler known as the controller decides whether to dynamically recompile the method with optimization, based on how the program is being used. For example, an accounting program might frequently use a method that computes account balances. By estimating how much time it would take to optimize the method, the controller figures out if it's worth dynamically recompiling the method with optimization. If the optimization would pay off, the controller invokes the optimizing compiler and gives it a "time budget" in which to do the job. The optimizing compiler caches the recompiled method in memory for later use.

Цитата trainer @ 16.09.05, 10:05

Да и я представляю требования к объему памяти.

Если выбирать JAVA, то такие требования лишены смысла

Тайлер, это все хорошо. В теории. Но прежде чем решить, надо собрать статистику. А на ее сбор и обработку(и перекомпиляцию) тратится время. Время выполнения этого кода.

Ты спрашивал, что знает JIT-компилятор, чего не знает обычный. Вот ответ. Насколько эффективно это реализовано - другой вопрос =)

З.Ы. Вообще-то те, кто создают такие компиляторы, наверное тоже осознают, что "прежде чем решить, надо собрать статистику. А на ее сбор и обработку(и перекомпиляцию) тратится время. Время выполнения этого кода". И учитывают это в своих разработках =)

Но ведь profiler не собственность JIT-компиляторов?

Добавлено 16.09.05, 11:13

Цитата Тайлер @ 16.09.05, 11:04

И учитывают это в своих разработках

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

Цитата trainer @ 16.09.05, 11:10

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

Ты мне все пытаешься доказать, что обычный скомпиленный код должен быть не медленне кода, выполняемого виртуальной машиной. Во-первых, я вовсе не пытался этого опровергать. Во-вторых, по теории это возможно. Если позитивный эффект адаптативной оптимизации будет превышать негативный эффект времени работы анализатора, то такой код будет работать БЫСТРЕЕ кода, скомпиленного обычным компилятором.

Кстати, приложениям JAVA можно ограничить прожорливость по памяти:

java -X
    -Xmixed           mixed mode execution (default)
    -Xint             interpreted mode execution only
    -Xbootclasspath:<directories and zip/jar files separated by :>
                      set search path for bootstrap classes and resources
    -Xbootclasspath/a:<directories and zip/jar files separated by :>
                      append to end of bootstrap class path
    -Xbootclasspath/p:<directories and zip/jar files separated by :>
                      prepend in front of bootstrap class path
    -Xnoclassgc       disable class garbage collection
    -Xincgc           enable incremental garbage collection
    -Xloggc:<file>    log GC status to a file with time stamps
    -Xbatch           disable background compilation
    -Xms<size>        set initial Java heap size
    -Xmx<size>        set maximum Java heap size
    -Xss<size>        set java thread stack size
    -Xprof            output cpu profiling data
    -Xrunhprof[:help]|[:<option>=<value>, ...]
                      perform JVMPI heap, cpu, or monitor profiling
    -Xdebug           enable remote debugging
    -Xfuture          enable strictest checks, anticipating future default
    -Xrs              reduce use of OS signals by Java/VM (see documentation)
    -Xcheck:jni       perform additional checks for JNI functions
 
The -X options are non-standard and subject to change without notice.

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

Цитата BugHunter @ 15.09.05, 14:52

Цитата

Сколько стоит обучение разработчика на С++

Дорого, очень и очень дорого.

У них дорого, у нас - дешево, так как никто не учит, а люди учатся сами.

-юсртыхэю 16.09.05, 15:07

Цитата Flex Ferrum @ 15.09.05, 15:00

Цитата BugHunter @ 15.09.05, 14:52

Дорого, очень и очень дорого.

Вот то то и оно. И именно за счет нетривиальных фишек С++. Хотя, если сейчас массово сажать новичков на boost и stl - проблем должно быть меньше...

Это лишь гипотеза.

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

Цитата Тайлер @ 16.09.05, 12:34

Если позитивный эффект адаптативной оптимизации будет превышать негативный эффект времени работы анализатора, то такой код будет работать БЫСТРЕЕ кода, скомпиленного обычным компилятором.

Так это только теория. С++ в теории тоже много чего может. Лучше рассматривать сгодняшние реализации и сравнивать их, а не теоретическую возможность чего-то там в неизвестном будущем.

Цитата nvm @ 16.09.05, 14:52

У них дорого, у нас - дешево, так как никто не учит, а люди учатся сами.

Наверное, поэтому у нас так много "хороших" программистов и такой "высокий" уровень продуктов.

Цитата nvm @ 16.09.05, 14:52

Аргументацией было бы сравнение результативности фирм, использующих stl+boost, и не использующих их вовсе.

Использование stl'я не является залогом успеха. Инструментом нужно уметь правильно пользоваться.

Цитата x0ras @ 18.09.05, 11:50

Лучше рассматривать сгодняшние реализации и сравнивать их, а не теоретическую возможность чего-то там в неизвестном будущем

Для чего лучше?

Цитата Flex Ferrum @ 16.09.05, 15:16

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

nvm решил не принимать вызов...

Сообщения были разделены в тему "Первая дуэль. "

Оффтопик:
Томми - робот, под управлением ОС Linux ПО, написанного на Java на скорости 70 миль в час(>100 километров в час) врезался в стену, тем самым "убив себя ап стену".

Вот оно! Доказательство, что java не тормозит!


http://www.linuxdevices.com/news/NS4678539635.html

mikv
А аналогичный робот, но программированный на C++, испытывался?

Цитата amk @ 15.10.05, 06:55

mikv
А аналогичный робот, но программированный на C++, испытывался?

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

Java = ТАСА (таса=фуфло!

Цитата Dr. Feronominol @ 15.10.05, 09:08

Java = ТАСА (таса=фуфло!

Мотивируйте. Слишком голословно.
А еще вы заблуждаетесь. Java практически незаменима для своих ниш.