>Похоже я от жизни отстал. В какой из реализаций C++ появился garbage collector?

Qt за собой мусор убирает.

>но даже там на графиках видно, что тригонометрия /да и не только - всё что связано с фпу/ нуууу оооочень тормозииит...

Полностью поддерживаю: я сравнивал реализации SNNS (нейронные сети) C/Java - С гораздо быстрее.

Сынок, так ты спрашивал про возможности жабы, а не телефонов. Ежу понятно, что клиент СУБД на телефоне никому не нужен, но там та же самая J2ME или MIDP. А ARM9 ставится не только на смартфоны (это я насчет embedded).

>Сынок, так ты спрашивал про возможности жабы, а не телефонов. ...На телефонах (дядя купи очки)

>Ежу понятно, что клиент СУБД на телефоне никому не нужен, А зачем заикался

>но там та же самая J2ME или MIDP. Только юзать там ее толком нельзя.

>А ARM9 ставится не только на смартфоны А это я в курсе.

>(это я насчет embedded). А это я про вот это ...В вашем телефоне (сотовом)....

2 GladAlex:
Ну насмешил :-). А если в любом из их конструкторов эксепшн вылетит - они уберут мусор за собой? ;-)..

Их останки сметет тот кто загрузил...

>Сынок, так ты спрашивал про возможности жабы, а не телефонов. ...На телефонах (дядя купи очки)

Так "на телефонах" или "телефонов"? Очки есть уже.

2 int19h

я тоже хочу букварик:)

torick@inbox.ru

2anonymous (*) (17.06.2004 13:20:21): "токо вот вопрос... а кто же писал оракловый инсталятор? И чего же он так тормозит? Может лохи писали? (хотя еще не проверял как работают проги под novm java, но думаю чудес не предвидится)"


"всё чудесатее и чудесатее..."

http://wwws.sun.com/software/looking_glass/

Это кстати так Вами нелюбимая и тормозная жаба. А инсталлер для Oracle писали один раз, писали через жопу, писали на скорую руку, писали очень давно, посему до сих пор Oracle можно поставить только туда, куда hard coded path показывает.

>Это кстати так Вами нелюбимая и тормозная жаба. А инсталлер для Oracle писали >один раз, писали через жопу, писали на скорую руку, писали очень давно, посему до >сих пор Oracle можно поставить только туда, куда hard coded path показывает.

не умеешь ставить оракл - не берись. оракл можно поставить в любую диру и никакого hard coced пути в инсталяторе нету.

> Я говорю о том, что циклы тут не причина, в том же скрине, если уж тебе лень глянуть Жаба с треском проиграла на перемножении матриц.

Если ты не заметил - я об этом повыше написал. И проиграла она именно потому, что этот тест закоден в виде цикла. Зато на тесте с числами Фибоначчи (рекурсивном) - стабильно обгоняет C++.

> Почему для java массива память выделяется за один раз, а для C++ - один раз плюс столько раз, сколько в массиве рядов?

А может, ты сначала яву подучишь? Поскольку в Java нет многомерных массивов, а есть только массивы массивов, оператор new int[][] совершенно аналогичен циклу из new int[]. Об этом явно сказано в Java language spec:

"For example, the declaration:

float[][] matrix = new float[3][3];

is equivalent in behavior to:

float[][] matrix = new float[3][]; for (int d = 0; d < matrix.length; d++) { matrix[d] = new float[3]; }"

>Так "на телефонах" или "телефонов"? Очки есть уже.

для начала процитирую вас

>В вашем телефоне (сотовом), если он конечно есть, тоже есть java >(если телефон не очень давнего производства), но боюсь он обладает >значительно более скромными параметрами, нежели заявленные вами.

Здесь явно идет речь о телефонах с поддержкой ява мидлетов - как правило имиджевые модели с бортовой памятью до 700 килобайт и как прецедент один из симменсов (модель навскидку не назову) с 2 метрами памяти (оперативной). Если тут вы имели ввиду смартфоны с АРМом - то характеристики у них (повторюсь) весьма некислые. И начинаются как минимум с 16 метров озу.

Именно по этому я и спросил "О! Расскажите нам про возможности явы на телефонах!"

Поскольку штука эта на телефонах, скорее из разряда "А У НАС НА КУХНЕ ГАЗ".

Кстати на большей части смартфонов АРМ (даже 9-й) почему-то по дефолту яву не может. Туда обычно JRE надо сначала накатить.

Наличие очков не подтверждает факт их применения.

Looking glass

родной, зачем вы нам показываете возможности OpenGL? какая разница, на чем написаны вызывающие ее функции?

Действительно все дело в JIT. Если запускать java -Xint ackermann 9 имеем ожидаемое большое время выполнения.

> родной, зачем вы нам показываете возможности OpenGL? какая разница, на чем написаны вызывающие ее функции?

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

void method(String arg, String arg) { print("blah, blah") ... }

void method(String arg, String arg) { print("blah, blah") ... }

который из методов написан на java а который на c++?

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

Так что темы Java vs C++ не в тему :)

а шо кресты быстрее? нет, значит сути дела не меняет..правда "ява быстрее C" вообще бы дико смотрелось

на яве System.out.println на c++ cout <<

> int - размером в машинное слово, > а оно может быть 1/2/3/4/5/6/7/8/9 байт

если я не ошибаюсь,

int не меньше 16 bit long не менее 24 bit ...

> void method(String arg, String arg) { print("blah, blah") ... }

> void method(String arg, String arg) { print("blah, blah") ... }

> который из методов написан на java а который на c++?

Ни тот ни другой, так как и в C++, и в Java параметры функции с одинаковыми именами недопустимы =)

> если я не ошибаюсь

Ошибаешся. Нигде в стандарте такого не сказано. Сказано только, что оно (sizeof) кратно char'у, и больше нуля

:))))))))))

>Язык написаый на С быстрее С++

Сам то понял, чего сказал?

> Pi (*) (17.06.2004 14:05:22):

FYI - Alpha - 64-битная платформа; тем не менее в Linux, FreeBSD, OpenBSD, DG-UX там sizeof(int)==4

sizeof(long)==8, sizeof(void*)==8

Такой int привёл к тому что ни одна база данных из доступных там или не собралась, или не работала. Это было в 2000-м, позже не пробовали.

> anonymous (*) (17.06.2004 18:32:08):

> 5) Из 3 вытекает, что на системах, с агрессивным кэшированием фс ( Linux ) old generation - реальный кандидат для пинг (swap in)-понга (swap out).

Вопрос скорее не в агрессивном кэшировании FS, а в unified Mach-styled VM. И в поведении Java GC в плане определения момента запуска GC.

Я подозреваю, что ситуацию существенно облегчит следующая логика работы: первая сборка запускается при достижении некоторого фиксированного объёма занятой памяти (например, 1/8 RAM), следующая - удвоенного объёма момента конца предыдущей сборки.

Да, эта логика изложена для случая "stop world GC", но она переносится и на более хитрые реализации.

> а что там, майкрософтовский WinForms и тот надписи и кнопки сам отрисовывает

В некоторых приложениях от MS можно заметить кнопки, списки и прочие объекты, _не имеющие своего окна_. То есть есть окно с кучей всякого, и в нём - кнопка, точь-в-точь как стандартная.

Я не копал, они перетащили код ButtonWndProc() или сделали такое же. Но отсюда растёт аргумент в пользу двухэтажной конструкции windows + widgets, как в X Window...

>А если в любом из их конструкторов эксепшн вылетит - они уберут мусор за собой? ;-)..

А какие проблемы проблемы с исключением в конструкторе? Вот в деструкторе проблем больше... У Саттера проблема разжевана, вывод один - в плюсах мусор автоматически корректно за собой убирать можно (и нужно ;).

2int19h:
>В тесте ackermann - жаба (с вышеописанными параметрами) в два раза >быстрее C++. Куда его дальше оптимизировать - я не знаю (есть >предложения?).

Ставите __fastcall перед функцией и получаете преимущество перед
жабой. Работает под Visual C++, Borland C++ & GCC.
Если заботит переносимость, можно проверать сделать макро типа
MY_FASTCALL и определять его по-разному в зависимости от платформы и т.д.
А если есть несколько мегабайт памяти, то можно ack(M,N) считать вообще
в сотни раз быстрее (для разумных значений N и особенно M), заведя
табличку предвычесленных значений.

fibo ускоряется аналогично - __fastcall для ленивых, табличка для
чуть менее ленивых и стандартный матричный O(log(N)) алгоритм для
остальных, который сделает любую тупую реализацию, написанную хоть на
ассемблере.

То есть это надо так понимать, что жабка делает для вызовов fastcall по возможности? C++, я так понимаю, не может, т.к. функция может потенциально быть вызвана из другого модуля (она там не static вроде)... интересно, а если ее как static объявить - он сможет соптимизировать это дело в fastcall.

А насчет оптимизации - я разумеется имел в виду C++-специфичные... а то как вы предлагаете - так и жабскую версию соптимизировать можно.

2int16h:
>> То есть это надо так понимать, что жабка делает для вызовов fastcall по возможности?
скорее всего да, я с java не работаю, но понятно, то jit компилятор
имеет гораздо больше свободы в этом смысле.

>> C++, я так понимаю, не может, т.к. функция может потенциально быть вызвана из другого модуля (она там не static вроде)

Делайте внешнюю функцию обычную (__cdecl) а из нее вызываете рекурсивную
__fastcall.

>> ... интересно, а если ее как static объявить - он сможет соптимизировать это дело в fastcall.

Теоретически да, практически не знаю.

>> А насчет оптимизации - я разумеется имел в виду C++-специфичные... а то как вы предлагаете - так и жабскую версию соптимизировать можно.

Я, собственно, к этому и веду.
Многие тут говорили, что "умеючи, на любом языке
можно написать быструю программу", и с этим можно согласиться.
Но когда алгоритм и реализация оптимальны, вот тут более низкоуровневые языки оказываются как правило быстрее, потому что
накладной расход, привносимый runtime поддержкой меньше.
Причем у высокоуровневых языков (а с современными компиляторами C/C++ такой эффект стал наблюдаться и у C программ) возможности
оптимизации ограничены - то есть часто более тупые с точки зрения C-программиста реализации работают быстрее более продвинутых, потому
что компилятору проще понять из тупой реализации, что имеется в виду.
То есть, у каждого языка есть некоторый уровень абстракции, на котором
скорость максимальна. Benchmark'и из shootout используют один уровень
для разных языков, что с одной стороны правильно, так как сравнивает работу одинаковых конструкций, но очень отдалено от жизни.
К тому же не учитываются эффекты больших программ, где у той же
Jav'ы включается garbage collection на полную катушку, где кэш
jit-скомпилированного кода возможно работает не оптимальным образом и т.д.

http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html жабка со своим double checked locking отсосала по полной..

В приличных языках эти шаблонные извраты просто не нужны.

> В приличных языках эти шаблонные извраты просто не нужны.

Это в FORTH, что ли?

> А какие проблемы проблемы с исключением в конструкторе?
Если exception не будет пойман внутри конструктора и вылетит наружу, то объект не будет создан... хотя operator new для него выполнится, а значит память будет уже выделена. В дальнейшем для объекта при delete просто не будет вызван деструктор... вот и все... а если в деструкторе эксепшн вылетел... гм... это имхо сразу значит что пришел тотальный ...дец :-).

>в плюсах мусор автоматически корректно за собой убирать можно (и нужно
> ;).
Речь шла про QT... :-)... которая с C++ работает несколько странно :-). А про то что автоматическую собиралку сделать можно - дыкть это вполне понятно :-).

> Это в FORTH, что ли?

Двенадцать.

> В приличных языках эти шаблонные извраты просто не нужны.

там вроде не про шаблоны речь. Я ничего не говорю, double checked locking это и в Си++ не портабельно, просто в жаве это вроде распространенная идиома..

> там вроде не про шаблоны речь. Я ничего не говорю, double checked locking это и в Си++ не портабельно

"double checked locking" - широко известный шаблон проектирования

> Если exception не будет пойман внутри конструктора и вылетит наружу, то объект не будет создан... хотя operator new для него выполнится, а значит память будет уже выделена. В дальнейшем для объекта при delete просто не будет вызван деструктор... вот и все... а если в деструкторе эксепшн вылетел... гм... это имхо сразу значит что пришел тотальный ...дец :-).

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

> "double checked locking" - широко известный шаблон проектирования

вроде уже договорились о правильной терминологии:) http://www.linux.org.ru/view-message.jsp?msgid=583487&back=view-group.jsp...

> "double checked locking" - широко известный шаблон

double checked locking это технический прием. Паттерн проектирования это синглтон.

> double checked locking это технический прием. Паттерн проектирования это синглтон.

:)

>> Нет такого правила. Более того -- в любом букварике, хоть как-то
>> затрагивающем переносимость тыкают носом:

> Гм ;-) SGI думают по другому... но вполне возможно...

Это проблемы SGI. Ибо действительно возможно.

> За ссылочку на бувкарик буду безмерно благодарен...

Programming in C++, Rules and Recommendadtions
Copyright (C) 1990-1992 by
Ellemtel Telecommunication Systems Laboratories

Можно спросить Google, например, так:
--- cut ---
"programming in c++ rules and recommendations" ellemtel
--- cut ---
и выбрать откуда качать и в каком формате по своему вкусу :)

> Только интересно, зачем из c++ long long убрали (8 байт), и как теперь называть его будут??? :) Или есть тип для чисел в 8-мь байтов?

Никто его не убирал -- его просто ещё не успели внести :-)

Просто текущий стандарт c++ базируется (если можно так выразится) на c89. А long long добавили только с99.

Стандарт C++ 15.2.2. Если объект создается через new и в конструкторе исключение память освобождается автоматически. Деструктор не вызывается, поскольку объект считается не созданным до завершения конструктора. То есть если если что-то опасное выделяем через new в конструкторе и оно успело выделится до исключения - оно в пролете. Вывод - ловим исключения в теле конструктора, освобждаем нажитое добро, если нужно кидаем исключение снова.

>> А какие проблемы проблемы с исключением в конструкторе?

> Если exception не будет пойман внутри конструктора и вылетит наружу, то объект не будет создан... хотя operator new для него выполнится, а значит память будет уже выделена. В дальнейшем для объекта при delete просто не будет вызван деструктор... вот и все... а если в деструкторе эксепшн вылетел... гм... это имхо сразу значит что пришел тотальный ...дец :-).

Неправильно. Читаем Final International Draft Standard ISO/IEC 14882:1998(E), Programming languages -- C++

15 Exception handling

15.2 Constructors and destructors

[...]

2. An object that is partially constructed or partially destroyed will have destructors executed for all of its fully constructed subobjects, that is, for subobjects for which the constructor has completed execution and the destructor has not yet begun execution. Should a constructor for an element of an automatic array throw an exception, only the constructed elements of that array will be destroyed. If the object or array was allocated in a newexpression and the newexpression does not contain a newplacement, the deallocation function (3.7.3.2, 12.5) is called to free the storage occupied by the object; the deallocation function is chosen as specified in 5.3.4. If the object or array was allocated in a newexpression and the newexpression contains a newplacement, the storage occupied by the object is deallocated only if an appropriate placement operator delete is found, as specified in 5.3.4.

Более правильный подход - использовать обертку auto_ptr для того что выделяется в конструкторе и не надо никаких обработчиков писать. В случае возникновения исключения память будет освобождена в деструкторе auto_ptr'а и никакого геммороя если, например, указалетей штук 10 и исключение стрельнуло на 5-м или еще каком нибудь.

> Деструктор не вызывается, поскольку объект считается не созданным до завершения конструктора.

Но вызывается для всех сконструированных подъобъектов

> То есть если если что-то опасное выделяем через new в конструкторе и оно успело выделится до исключения - оно в пролете

Ещё раз:

If the object or array was allocated in a newexpression and the newexpression does not contain a newplacement, the deallocation function (3.7.3.2, 12.5) is called to free the storage occupied by the object; the deallocation function is chosen as specified in 5.3.4.

>>но даже там на графиках видно, что тригонометрия /да и не только - всё что связано с фпу/ нуууу оооочень тормозииит...

>Полностью поддерживаю: я сравнивал реализации SNNS (нейронные сети) C/Java - С гораздо быстрее.

Поправьте меня, но там по моему нет ни одного теста вычислений операций с плавающей точкой (в т.ч. в цикле). Мой опыт говорит, что ява тормознее в данном случае раза в 1.5

Хотя проектанты Looking Glass похоже пытаются опровергнуть мнение о тормознутости явы:

http://www.infoworld.com/article/04/05/21/21FEinnovwatch_1.html?s=feature