Конец Java? (3 стр)

ud1
> В С++ можно самому как угодно организовать пул,вот только как правило это не требуется.
Ключевое слово - организовать, Вам надо трудится, мне нет, я лучше логику делать буду.
Насчет не требуется, тут вопрос в задаче, есть много задач, где требуется.
ud1
> Отсутствие инклудов приводит к необходимости компилятору искать нужные классы
> по всем импортируемым файлам, что приводит к замедлению компиляции.
уж скорость компиляции !больших! проектов на яве куда быстрее. До сотни классов за 3-4 секунды.
ud1
> Я говорю, что в С++ для создания объекта в стеке вообще ничего не нужно, а в
> жаве это как минимум вызов нетривиальной функции + скажем конструктор по
> умолчанию обнуляющий члены.
стек, таки вещь для локальных данных. Чтобы их сохранять дальше - надо либо копировать целиком данные, либо создавать в куче.
ud1
> К тому же сборка мусора способствует написанию говнокода, если в С++ нужно
> продумывать, кто где создает объекты, и когда их удаляет, что приводит к более
> тщательной разработке и структурированию кода, то в java будет уже просто
> мешанина, кто кто хочет, тот что угодно и делает.
слишком все голословно. Думать надо и там и там, просто на Яве не надо заниматься тем, чем обязательно придется на С++
Но никто не мешает грамотному программисту грамотно структурировать код на Java.
Можно также спокойно заявить, что отсутствие сборщика мусора приводит к утечкам памяти.
Дело не в инструменте, дело в программисте.
Инструмент может лишь помогать. Вот в этом и идет сравнение.
ud1
> Далее хранение и кода и описания в одном и том же файле может ухудшить
> читабельность кода.
это религиозный, а не практический вопрос.
ud1
> protected работает не так как в С++.
смешно, а почему protected в C++ не работает так как в Java, а?

Блин, тема изначально касалась лишь Жабистов.
Нет влезут тут всякие :)
И самое интересное, что лезут то в основном плюсисты всегда :)
Может у них жизнь тяжелая.

_g
> да и сравнивать Java с C++ — глупо. а вот с .NET — вполне можно.
Что java, что C#, они на одно лицо. Вот только java интерпретируемый язык, и поэтому хотелось бы увидеть в нем море возможностей недоступных компилируемым языкам, но он, почему-то, по всем параметрам сливает С++. Но по крайней мере java знает свое место - написание простеньких небольших програм для телефонов, тостеров и веб-браузеров, может быть как скриптовый язык к играм, он занимает эту нишу и претензий к нему у меня нет. Но C# возомнил себя богом и хочет заменить собой все, включая С++. Опытные программисты С++, почувствовавшие всю его красоту и мощь никогда не променяют его на C#, вот только новым программистам, продавшим душу микрософту, не хватит сил и времени чтобы освоить С++, и C# захватит мир. Пожалуй быстрые компьютеры и ооочень тормозное ПО давно являются символом 21 века.

ud1
Очнитесь, уж десяток лет корпоративное ПО, EIS,ERP пишутся на Java и только недавно туда пошел и С#.
ud1
> Вот только java интерпретируемый язык,
Java не интерпретируемый, а динамически компилируемый язык.
ud1
> и поэтому хотелось бы увидеть в нем море возможностей недоступных компилируемым
> языкам,
ORMы

ud1

> но он, почему-то, по всем параметрам сливает С++

в скорости разработки (кроссплатформенных) приложений - выигрывает.

> Но по крайней мере java знает свое место - написание простеньких небольших програм для телефонов, тостеров и веб-браузеров

60% ПО, что я использую в труде и обороне - написаны на Java: от среды разработки, до каких-нить VCS-тузлы или редактора диаграмм.

Серый крокодильчик
> ЕМНИП, там специальные пулы только для компонентов.

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

AvrDragon
"С++ никогда не умрет" - так сказал один мой коллега на фирме Априорит. Ну не буду пускаться в подробности, но он сказал что С++ это тру.

TarasB
> Короче, не знаю про билдеровский, но дельфовский (в билдере не такой же разве)
ну дельфи, это дельфи. В билдере только VCL прикреплена посредством импорта из длл. А сам С++, там как обычный С++.
Ну правда он местами не соотвествует стандарту сильно.

Zheka_Dnepr
Как бы, ни асм, ни фортран - не умерли до сих пор :)

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

Лолчё? Про отсутствие модулей и скорость компиляции вам, плюсистам, лучше молчать.
И джава разве перебором ищет класс по имени?! Это не смешно.

Серый крокодильчик
> В билдере только VCL прикреплена посредством импорта из длл.

То есть переписать дельфовский менеджер на Си они не смогли?

TarasB
> То есть переписать дельфовский менеджер на Си они не смогли?
что для компонентов и всех VCLвских классов он есть знаю
Применяется ли он в случае
int* p = new int[100];
не знаю, мне говорили, что нет. Но пруфов не имею

Zheka_Dnepr
слава срезке!

Den Zurin
> ТруЪ Жаба - это Java 1.4.
> Или взять те же хваленые шаблоны C++. В Java же шаблоны просто не нужны - можно
> использовать класс Object, а примитивные типы (int, char и т.д.)
> преобразовывать в классы с помощью классов-оболочек. Правда, в 5-ю версию все
> же непонятно зачем добавили шаблоны.
> Вообще, ООП в Java ближе к Smalltalk/Objective-C, чем к C++.

Как человек, пописавший на Java некоторое время готов заказать тебя киллеру. В C++ можно все хранить как void*, готов поспорить тебе понравится.  Небось лямбды тебе тоже не нужны? Элвис-операторы фуфел? В топку прогресс, в топку контроль типов, в топку все, что выло позже 4й жабы.

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

TarasB
> Лолчё? Про отсутствие модулей и скорость компиляции вам, плюсистам, лучше
> молчать.
Ага, фэйл, проект на плюсах за 10-20 минут не собирается, эт точно

А вот про скорость работы - опять таки жаба в основном проигрывает из-за подхода к программированию "давайте срочно нафигачим вот эту штуку, заказчик не нещеброд, купит сервер помощнее, но на день раньше выкатим версию". Если писать на жабе как на плюсах, то падение производительности меньше 50%.

И вообще моё мнение - каждого жабиста надо на недельку посадить писать на С в ring 0 без виртуалки и кернел дебагера. Тогда они перестанут править код только после того как запуск тестового сценария вылетел с эксепшеном и удивляться тому что соккеты надо руками закрывать, а не ждать пока GC пройдется финалайзом.

CAJ
> что соккеты надо руками закрывать, а не ждать пока GC пройдется финалайзом.
если у вас такие жаба программисты, то я вам сочувствую.
Но не в языке дело.
У меня Ведьмак, даже после патчей, постоянно с мемори ликами падает через сколько-то минут игры.
А написан он на С++.
CAJ
> Ага, фэйл, проект на плюсах за 10-20 минут не собирается, эт точно
буст сколько собирается?
CAJ
> но на день раньше выкатим версию
но из-за на день раньше, рынок оккупирует именно эта система, и весь профит с рынка снимает она.

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

akaAngeL

> Photoshop на Си без классов.

GIMP же

Серый крокодильчик
> У меня Ведьмак, даже после патчей, постоянно с мемори ликами падает через
> сколько-то минут игры.
> А написан он на С++.
А у меня не падает. У меня спец сборка на яве?

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