Да вам просто нечего больше сказать, вот вы и издеваетесь (Божественный, Великий Хакер). А сами-то вы вообще кто? про невозможность С без ассемблера вы чё-то промолчали, а как ява, так сразу полезли искать какие-то *.so. По поводу libzip.so - это юзает сама JVM, хотя бы для того чтобы rt.jar открыть.

>Но мудрейшему не мешало бы объяснить, зачем сан включает в JRE libzip.so ?
А с помощью чего будет разворачиваться rt.jar? :))

>И в чем же будет говно? Можно поподробней?

Конечно можно.
Вот что будет. Это полная х***я. Хорошо хоть разделить смог, fdivl 
подставил..

08048430 <main>:
 8048430:       8d 4c 24 04             lea    0x4(%esp),%ecx
 8048434:       83 e4 f0                and    $0xfffffff0,%esp
 8048437:       ff 71 fc                pushl  0xfffffffc(%ecx)
 804843a:       55                      push   %ebp
 804843b:       89 e5                   mov    %esp,%ebp
 804843d:       51                      push   %ecx
 804843e:       83 ec 34                sub    $0x34,%esp
 8048441:       c7 04 24 00 00 00 00    movl   $0x0,(%esp)
 8048448:       c7 44 24 04 00 00 f0    movl   $0x3ff00000,0x4(%esp)
 804844f:       3f
 8048450:       e8 33 ff ff ff          call   8048388 <sin@plt>
 8048455:       dd 5d e8                fstpl  0xffffffe8(%ebp)
 8048458:       c7 04 24 00 00 00 00    movl   $0x0,(%esp)
 804845f:       c7 44 24 04 00 00 f0    movl   $0x3ff00000,0x4(%esp)
 8048466:       3f
 8048467:       e8 ec fe ff ff          call   8048358 <cos@plt>
 804846c:       c7 04 24 00 00 00 00    movl   $0x0,(%esp)
 8048473:       c7 44 24 04 00 00 f0    movl   $0x3ff00000,0x4(%esp)
 804847a:       3f
 804847b:       dd 5d d8                fstpl  0xffffffd8(%ebp)
 804847e:       e8 f5 fe ff ff          call   8048378 <tan@plt>
 8048483:       dd 45 d8                fldl   0xffffffd8(%ebp)
 8048486:       dc 4d e8                fmull  0xffffffe8(%ebp)
 8048489:       d9 c9                   fxch   %st(1)
 804848b:       dc 75 e8                fdivl  0xffffffe8(%ebp)
 804848e:       de c1                   faddp  %st,%st(1)
 8048490:       d9 5d f4                fstps  0xfffffff4(%ebp)
 8048493:       d9 45 f4                flds   0xfffffff4(%ebp)
 8048496:       dd 5c 24 04             fstpl  0x4(%esp)
 804849a:       c7 04 24 80 85 04 08    movl   $0x8048580,(%esp)
 80484a1:       e8 c2 fe ff ff          call   8048368 <printf@plt>
 80484a6:       83 c4 34                add    $0x34,%esp
 80484a9:       31 c0                   xor    %eax,%eax
 80484ab:       59                      pop    %ecx
 80484ac:       5d                      pop    %ebp
 80484ad:       8d 61 fc                lea    0xfffffffc(%ecx),%esp
 80484b0:       c3                      ret

Это ему повезло ещё что я от phi считал.. он почти выкрутился. Но это его не реабилитирует.

> Меня интересует возможность тупо решить поставленную задачу. Подход С++ где надо городить нетривиальный темплейт для простой callback- сущности и оборачивать ее в смарт-указатель (другой нетривиальный темплейт) чтобы определить политику владения меня не воодушевляет.

Меня воодушевляет такая возможность (ибо я смогу поменять ее реализацию на другую, твикнутую под меня реализацию, если потребуется),

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

>> Ну Вы же понимаете, что проигрыш в 2 раза например в геймдеве это слишком много.

> Вот потому на яве игры и не пишут :)

На самом деле игры на Java пишут (для мобильников, например). Но это такой кошмар, когда эмулируют с помощью ООП структурно-ориентированный подход и даже Фортран — якобы для того, "штобы не тормозило". И ведь, действительно, такие проги не тормозят!!! :) И это считается хорошим тоном у геймдевелоперов.

Во што они превращают ООП в своих поделиях? В МЯСО, которое "разбрасывается" кусками там и сям (благо, что размер кода не переваливает аз несколько тысяч строк — можно обозреть одному программисту за несколько дней). А ну как в обычных девайсах отменят ограничение на размер JAR, что тогда? Будет полная ЗА..ЦА! Геймдевелоперы-мобильщики не эволюционировали дальше примитивных объектов-представлений персонажей и канвы, которые используются исключительно в стиле автоматного управления.

Объясни, почему "Это полная х***я".

Если тебя волнует что нет инструкции fptan, а есть call 8048378 <tan@plt> -- значит ты не те ключики поставил компилятору.

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

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

>Объясни, почему "Это полная х***я".
>Если тебя волнует что нет инструкции fptan, а есть call 8048378 <tan@plt> -- значит ты не те ключики поставил компилятору.

"Ключики", зависисмость от архитектуры процессора, макроопределения, один язык над языком другим языком погоняет...

Возьмите javac или pascal, или modula: один язык, на котором пишет человек, -->> один (байт)код выполняющийся на машине.

Вот в чём преимущества — в ОДНОЗНАЧНОСТИ порождаемого кода. Ну а JIT можно и подкручивать так же, как и GCC, но пусть это делают системщики, которые ЛУЧШЕ разбираются в архитектуре конкретного процессора — оставьте оптимизации прикладного кода прикладникам, системного кода — системщикам. Так будет лучше, так будет Unix-wayнее.

>>Но мудрейшему не мешало бы объяснить, зачем сан включает в JRE libzip.so ?

> А с помощью чего будет разворачиваться rt.jar? :))

C помощью ZipAndUnzip.class, написанном на Божественной Яве!!!

>>Объясни, почему "Это полная х***я".

>>Если тебя волнует что нет инструкции fptan, а есть call 8048378 <tan@plt> -- значит ты не те ключики поставил компилятору. >"Ключики", зависисмость от архитектуры процессора, макроопределения, один язык над языком другим языком погоняет...

А ты не сливай. Я Великого Хакера просил показать кусок кода на С, от ассемблерного листинга которого у меня бы волосы дыбом встали... ну экстремал я, знаешь ли...

>>А с помощью чего будет разворачиваться rt.jar? :))
>C помощью ZipAndUnzip.class, написанном на Божественной Яве!!!

"ZipAndUnzip.class" наследуется от java.lang.Object в rt.jar, а её всё ещё нельзя развернуть. :))

>>Но мудрейшему не мешало бы объяснить, зачем сан включает в JRE libzip.so ?

> А с помощью чего будет разворачиваться rt.jar? :))

Да и вообще! Еретик!!! Как тебе вообще могла прийти в голову мысль доверить что-либо, даже и мелочь, Опасному И Тормозному С, если это можно сделать на Божественной, Безопасной и Быстрой Яве???

>>> А с помощью чего будет разворачиваться rt.jar? :))

>> C помощью ZipAndUnzip.class, написанном на Божественной Яве!!! >"ZipAndUnzip.class" наследуется от java.lang.Object в rt.jar, а её всё ещё нельзя развернуть. :))

Ну хоть унылый троллинг кончился.

Вот только я посмотрел rt.jar -- и не нашел в нем Object.class :-)

Я понимаю, что щас ты скажешь, что еще нужны хххFile.class, и его родители -- но ради увеличения скорости и надежности работы Божественной Явы можно было бы добавить пару метров классов вне архива к уже имеющимся 100 метрам? И даже можно было бы распаковать _весь_ rt.jar ?

> Да вам просто нечего больше сказать, вот вы и издеваетесь (Божественный, Великий Хакер).

Конечно я издеваюсь. Но это потому, что вы очень уверенно высказываетесь о том, о чем знаете очень мало.

А если бы разговор шел о недостатках плюсов например, и вы бы по делу их критиковали, да еще и предлагали альтернативные решения -- я бы не издевался.

> А сами-то вы вообще кто?

Я -- искатель филосовского кам^W^W языка программирования, который бы нравился всем -- и прогерам на яве, и таким как я, любителям на ходу подменить реализацию виртуальной диспетчеризации :-)

>Вот только я посмотрел rt.jar -- и не нашел в нем Object.class :-)

Плохо искал. java/lang/Object.class в rt.jar

>>Вот только я посмотрел rt.jar -- и не нашел в нем Object.class :-)

>Плохо искал. java/lang/Object.class в rt.jar

Согласен. Но я не сказал что его нет -- я сказал что не нашел.

Он там не по алфавиту оказался, а в самом конце :-(

Кстати, в моем rt.jar (5МБ) разархивированная директория java занимает 12МБ -- не очень много.

не очень много -- это конечно по сравнению со всей явой, занимающей 100М.

> Предъява была к тому что биттрах на жаве не пишется и все JRE - это биндинги к библиотекам на Си. Я показал что за редким исключением это не так.

Щаса я еще одно "редкое исключение" выложу -- массой 8М, т.е. сравнимой со ВСЕМ rt.jar -- он весит 50М. Итак,

jre/lib/i386/server/libjvm.so

У меня вопрос. Почему 8-метровая libjvm.so (надо полагать, там как раз лежит Гениальный Код JIT/Hostspot , осуществляющий разные оптимизации во время выполнения, приводящие к Огромной Скорости Выполнения) написана на Опасном И Медленном С, а не на Божественной Яве?

Особенно если учесть что биттрах очень хорошо пишется на Божественной Яве?

Особенно если учесть, что Божественная Ява Идеально Подходит Для Многопоточных Программ (коим видимо должен быть JIT Сompiler) И Идеально Интегрируется C Выполняемй Внутри Нее Явой?

> Кстати, в моем rt.jar (5МБ) разархивированная директория java занимает 12МБ -- не очень много.

Кстати, в моем rt.jar (50МБ) разархивированная директория java занимает 12МБ -- не очень много.

>У меня вопрос. Почему 8-метровая libjvm.so (надо полагать, там как раз лежит Гениальный Код JIT/Hostspot , осуществляющий разные оптимизации во время выполнения, приводящие к Огромной Скорости Выполнения) написана на Опасном И Медленном С, а не на Божественной Яве?

У вас истерика, кроме того вы мне приписываете взгляды которые я никогда не озвучивал -> cлив засчитан.

> У вас истерика,

любопытно :-)

>кроме того вы мне приписываете взгляды которые я никогда не озвучивал

я сначала тебя по-другому понял -- может я и ошибся

> -> cлив засчитан.

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

Абсурд, я правда тебя не понимаю. Ты же вроде поборник скорости? Чего ты в этой яве нашел?

Думаешь она удобна синтаксисом? Это только кажется. Если в ней shared_ptr синтаксически сокращается до нуля, то кроме него сану все таки пришлось ввести WeakReference, PhantomRefernce, FinalRefernce, SoftReference, которые записываются так же отвратно, как и на С++. А если ты захочешь, чтобы кто-то для тебя создал AbsurdRefernce, которое будет нетривиально взаимодействовать со сборщиком мусора, то не факт, что он сможет это сделать сам, без сана.

Я ее изучаю конечно... но в общем, чтобы потом "всем другим рассказывать, какой это быдлоязык" (С) Абсурд.

>>Хотя мне кажется, что ява 10% времени занимается виртуальным вызовом... или хотя бы 5.

>Бедьненький. Ну прочитай ты про микробенчмарки. И про то, как VM оптимизирует твои несчастные двойные диспетчеризации и инлайнит их в рантайме.

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

И еще. Если С++ похож на тортик с битым стеклом внутри, то ява -- это пачка мокрой макулатуры. Так что я предпочитаю выковыривать стекла из тортика.

> и посмотри какое говно с точки зрения ассемблерщиков он сгенерирует.

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

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

>> Томми, перепиши libjpeg.so на чистой яве, чтобы работало быстрее сишного исходника -- тогда и поговорим.

>Напишите хоть какую-то реализацию jpeg'a. Хотя бы на С.

Зачем писать? Та, что уже есть, быстре чем чисто явовская. А вот фанатики пусть пытаются обогнать на своей яве С++ -- может, поумнеют...

>> Дело в том, что рабработчики на всяких пистонах и прочих перлах не орут на каждом углу, что выбраная ими технология быстрее Ц. В отличие от.

>Дайте, пожалуйста, ссылку, где SUN орет о том, что жаба быстрее Ц.

В О Т О Н А ! ! !

http://blogs.sun.com/dagastine/entry/java_is_faster_than_c

Сан конечно сам такие вещи (ява быстрее с) говорить не будет, но проплачивает тех, кто такое говорит, и даже держит такого рода фенечки у себя в блогах (но некоторое приличие, в виде замечаний в комментах, что "сравнение нечестно так как МС С++ устарело" все же сохраняет).

Там нынешнюю 6-ю яву сравнивают с древним 6-м вижуал С++.

Ява быстрее чем С?

А вот еще одна ссылка на тему "Ява быстрее чем С", уже даже не в блогах, а типа техническая статься сана!

http://java.sun.com/developer/technicalArticles/WebServices/javaC_LRWP/

Они там откопали откуда-то веб сервер Xitami, у которого явно проблемы в соларисе (Running a copy in each zone improved performance by more than 100% but still was not the solution to the scalability problem with Xitami), после чего успешно его победили явой, которая, думаю всем это ясно, с соларисом очень дружит.

И после этого кто-то еще не согласен с моим выражением "маркетоидный пиздежь" ?

Xitami в статье назван "один из топ 10 веб серверов". Кто-нить из вас раньше слышал об этом Выдающемся Веб Сервере Всех Времен И Народов хоть раз? Почему-то в стабильном дебиане (20 000 пакетов) его нет, хотя лицензия двойная: GPL+что-там ...

З.Ы. Абсурд прав. У меня истерика :-)

Вот обзор серверов за июнь: http://survey.netcraft.com/Reports/200806/

Мне кажется, что Xitami входит в первую десятку под категорией Unknown :-)

Нашел я наконец этого Гиганта -- на момент написания Технической Статьи Великого Сана По Божественной Яве он находился на более чем 80-м месте, имея распостраненность в 0.006% от распостраненности апача по количеству сайтов.

http://survey.netcraft.com/Reports/200708/

Сколько ещё это будет продолжатся? Хотя результаты на лицо. Некоторые жабокодеры уже стали сомневаться в троекратном превосходстве Java над Си, как им благополучно наврали сановцы.

>Абсурд, я правда тебя не понимаю. Ты же вроде поборник скорости? Чего ты в этой яве нашел?

Реализованы теоретические предположения о managed коде. Модель памяти отлична от массива вида char mem[2^PTR_BITS]. Язык весьма консистентен.

>то кроме него сану все таки пришлось ввести WeakReference, PhantomRefernce, FinalRefernce, SoftReference

Ты хотя бы утруждал себя вопросом - зачем они в Яве нужны?

>которые записываются так же отвратно, как и на С++

Все семантическое разнообразие С++ в этом вопросе предназначено для того чтобы сделать очередной быдлоподсчет быдлоссылок.

>>то кроме него сану все таки пришлось ввести WeakReference, PhantomRefernce, FinalRefernce, SoftReference

>Ты хотя бы утруждал себя вопросом - зачем они в Яве нужны?

Конечно. Удивительно другое. Удивительно как можно вообще без них жить... но жили, поскольку программили только быд^W поделия не слишком высокой сложности.

Вот простейший пример. На яве надо написать кэш чего-нибудь (например картинок, скачанных из инета с помощью Великого Браузера На Чистой Яве -- как он там назывался?). Но проблема в том, что объект (картинка), лежа в кэше, держит на себя активную ссылку, и даже когда все страницы, реально юзающие картинки, закрыты, одна ссылочка-то остается! Нам либо надо тупить, занимаясь своей сборкой мусора, что может быть совсем не просто, если объемлющие объекты раскиданы по всей аппликухе, а не собраны в удобный массивчик, как страницы в браузере, либо юзать в кэше WeakReference.

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

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

В Божественной Яве все разнообразие в этом вопросе предназначено для... ну в общем для того же, что и в плюсах :-)

Одно уточнение. WeakReference нужна для неинтрузивного кэша с довеской чего-то там еще, если же ты можешь ковырять код объектов которые в нем лежат -- то без WeakReference можно обойтись.

А вообще неинтрузивность -- это хороший тон, даже если ты сам эти объекты и пишешь.

Так вот, тем кто думает, что в яве указателей нет -- сюрприз! Они есть, называются WeakRefernce, и могут неожиданно обнулится. Короче: так же, как и в С, только будет exception. Если в линуксе сигнал обернуть в С++ эксепшн и добавить выяснялово "кто там на стеке был 0", то (прошу меня поправить) получится то же самое.

A еще WeakRefernce полезны для разрушения циклических структур.

> Кстати, в моем rt.jar (50МБ) разархивированная директория java занимает 12МБ -- не очень много.

Потому что ява-байткод в классах плотнее чем нативный в ELF-формате. Вот и размер меньше.

> Так вот, тем кто думает, что в яве указателей нет -- сюрприз! Они есть, называются WeakRefernce, и могут неожиданно обнулится. Короче: так же, как и в С, только будет exception. Если в линуксе сигнал обернуть в С++ эксепшн и добавить выяснялово "кто там на стеке был 0", то (прошу меня поправить) получится то же самое.

Вот уж не надо: в C++ будет segfault и п**ц приложению и никакого иксепшна, а ловить сигнал - бесполезное занятие. в яве будет иксепшн, который хотя и помешает работе, но не фатален. Кроме того, этоа ваша WeakReference весьма редко используется и уж если кто юзает, то уж конешно будет поглядывать за ней (уж на null то проверить всегда не мешает, а уж такую хрень просто обязательно). В любом случае вариант написания полной х**ни мы не рассматриваем.

> A еще WeakRefernce полезны для разрушения циклических структур.

Вот это не говорите глупости. На циклические структуры яве наплевать. Выбросит всех если надо. Анализ достижимости называется.

В общем вы всё время упираете в вещи, которые используются ну реально редко. Почти все классы которые я лично ежедневно использую из rt.jar, я почти все их прочёл и убедился что там всё отлично написано. И биндинги к С содержат именно сокеты, файлы и блокировки. UI-щики добавят ещё что в awt есть биндинги к С, а точее к opengl. Всё остальное используется не часто. Вы бы ещё нашли какого барахла в яве и сказали что вся ява на нём держится. Основные алгоритмы держатся на HashMap, ArrayList, HashSet, ConcurrentHashMap, нкоторое количество реаизаций Queue и Deqeue. Для ввода вывода некоторое количество InputStream и OuputStream'ов. (они почти все на яве, у File*Stream есть биндинг к С). Вот каркас приложений. И не надо мне рассказывать что код jpegencoder или какая-то там unusedReference кому-то мешает и что именно они и выполняют всю грязную работу за яверов.

> Не знакомы аббревиатуры C99, C++98, C++0x? аббривеатуры знакомы, но только что в них входит? как я понял из Вики C++0x еще не до конца доведен.

А какие компиляторы + "среды исполнения" поддерживают C99 и С++98?

> Разве работоспособность программы на C/C++ зависит от "исполнителя среды"?

Конечно. Или вы хотите сказать, что написав программу работающею по HTTP под Linux я легко ее скомпилирую и запущу под MS DOS? или под Виндовозом???

У С/С++ среда исполнения это требуемые для работы библиотеки и набор ядерных АПИ.

PS я пришу "среда исполнения" в ковычках потому что это не термин, а понятие ))) Или как можно более правильно охарактеризовать необходимый для запуска набор предусловий типа ядерный АПИ + наличие библиотек и т.п ?!?

Да, и вот ещё немного про UnusedReference. Да, эти референсы выглядят стрёмно, поэтому я лично их не использовал когда надо было делать кэш, потому что существуют другие признаки для инвалидации кэша. А вообще я не применяю кэши в чистом виде, а предпочитаю другие средства оптимизации. Так что ваши референсы весьма экзотичны.

Кроме того, даже если считать что все эти Чудо Необходимые для Жизни Референсы, то всё равно их синтаксис на порядок чище и аккуратнее соответсвующих бредней в крестах. По части синтаксиса и библиотеки спорить вообще не о чём. В яве Collections API, Concurrent API и ещё ряд выжных вещей - просто шедевры. Их УДОБНО и ЛЕГКО использовать, а функционал не уступает сишным анаолгам. Они элегантны и качественны. И код их использующий тоже красив. Кресты так не умеют. И синтаксис местами просто уродский и нифига не читается этот stl'ный бред. Даже у паскаля и то лучше выглядит временами, хотя я его и недолюбливаю. Так что я бы сказал что тот тортик о котором вы говорили обманчив, скушаешь кусочек - наешься стекла. А тут чистая выжимка - надо только не подавиться, от чего все и страдают. Опьянённые простотой городят всякую хренотень, а потом удивляются что тормозит.

>> A еще WeakRefernce полезны для разрушения циклических структур.

> Вот это не говорите глупости. На циклические структуры яве наплевать. Выбросит всех если надо. Анализ достижимости называется.

Ты вроде даже и русский не знаешь. Я сказал "полезны", а не сказал "обязательно необходимы".

Нет, не полезны. Какая же тут польза? зачем размыкать циклические ссылки? да плевать на них. Вот буду я ещё тратить ресурсы на их размыкание. Сборщик мусора и так выявит негодяев. А ещё эти UnusedReference будут JVM грузить своими глупостями (какие там хуки, кто знает....). Бррр.

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

> Ой, а что это за странные строчки в начале программы на яве: "import java.lang.String". Наверно это подключение какой-то библиотеки?

Это заметка компилятору, что в дальнейшем коде при нахождении класса с именем String нужно использовать java.lang.String. Для удобства написания кода чтобы уменьшить число букафф.