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

Во! Вот правильные слова. Я как-то криво высказался, имея ввиду именно это.

> Так что ваши референсы весьма экзотичны.

Чудо Инженерной Мысли Эклипс, которое ява-фаны часто приводят как Показательный Пример Того Что Без Божественной Явы И На Другом Языке Не Написать, использует софт референсы.

> то всё равно их синтаксис на порядок чище и аккуратнее соответсвующих бредней в крестах.

В переводе на русский язык: "я не знаю, как это делается в крестах, но надо же их как-то обосрать... скажу общую фразу о преимуществе явы"

java:
Widget widget = new Widget();
WeakReference<Widget> weakWidget = new WeakReference<Widget>(widget);
widget.show();

c++:
Widget* realWidget = new Widget();
shared_ptr<Widget> widget = realWidget;
widget->show();

Хм... на с++ покороче вышло... но в общем с явой будет просто перестановка слагаемых.

Объясните мне, зачем вы приплели WeakReference в таком простом случае?

new Widget().show();

Вот и всё.

если ссылка на него нужна, то просто

Widget widget = new Widget(); widget.show();

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

> В Принципе, у UnusedReference есть свои применения, но это экзотика.

UnusedReference? ну скажи, скажи, какие у них применения в яве... :-)

>Объясните мне, зачем вы приплели WeakReference в таком простом случае?

Чтобы показать тебе их синтаксис в яве и в плюсах, который почти одинаков. Поскольку ты (необосновано) написал:

> даже если считать что все эти Чудо Необходимые для Жизни Референсы, то всё равно их синтаксис на порядок чище и аккуратнее соответсвующих бредней в крестах.

Сравни синтаксис при использовании итераторов. Сразу станет видно.

> UnusedReference? ну скажи, скажи, какие у них применения в яве... :-)

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

В принципе, удобно юзать WeakReference<String,Image> для кэширования подгруженных картинок, но это опять же можно сделать иначе. Надо только захотеть.

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

> c++:
> Widget* realWidget = new Widget();
> shared_ptr<Widget> widget = realWidget;
> widget->show();

Java:
Widget widget = new Widget();
widget.show();

weak-reference нафиг не нужно ;) Особенно если пользоваться не умеешь ))))

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

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

В каком вопросе разнообразие? Быдлоподсчета быдлоссылок в мейнстримной Яве нет.

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

Кстати длина строк не играет большой роли, потому чтобы набрать WeakReference мне достаточно написать WR <Ctrl-Space>. А вот в сях придётся всё честно набирать. но это уже вопрос IDE, его сюда ешё не хватало :D

и до тебя тоже не дошло, что это пример использования не для дела, а для показа синтаксиса

> В каком вопросе разнообразие? Быдлоподсчета быдлоссылок в мейнстримной Яве нет.

Подсчёта ссылок в яве вообще давно уже нет. Говорю же: анализ достижимости. Это не одно и то же.

> В каком вопросе разнообразие?

В вопросе разных референсов

> Быдлоподсчета быдлоссылок в мейнстримной Яве нет.

А, точно... там же Божественный Сборщик Божественного Мусора!

> Да Ё-маЁ. Вот ведь прицепились-то а. С/С++ извольте сравнивать с нативными языками. Никто не пытается хай-перфоманс на яве выжимать. Просто факт - ява не так уж сильно уступает. Кроме того, ява это не просто урезанный С. Ещё раз повторяю: хватит с крестами всё сравнивать. У крестов свой сектор применения, у явы свой. Вот С в энтерпрайз применить.. посмотрю я на вас, будете как 10 лет назад ковыряться. Никто не позиционирует яву как высокопроизводительную. А если кто и пытается серьёзно сравнивать яву с С по скорости, то он теряет время зря. Сила явы не в скорости и никогда никто не позиционировал так, даже тогда когда JIT появился.

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

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

>> Быдлоподсчета быдлоссылок в мейнстримной Яве нет.

>А, точно... там же Божественный Сборщик Божественного Мусора!

Истерика продолжается. Еще один слив засчитан.

>> В каком вопросе разнообразие?
> В вопросе разных референсов

Разные референсы в Java не нужны в 95% случаев. вероятно есть необходимость, он сверх редкая.

Всегда используется базовый референс создаваемый конструкцией:
Widget widget;
В отличии от С++ это именно референс, а не объект создаваемый на стеке.

Божественный Мусор плодят Божественные Программеры ;) ( и Великие Хакеры :D ) Все остальные создают обычный такой, стандартный мусор... сборщик его вообще игнорирует - будет он ещё заниматься всякой бытовухой :D Он вообще только за UnusedReference наблюдает под микроскопом, мало ли кто прохавает ссылочку.. и всёёё... в общем кругом халтура.. ай яй яй...

> вероятно есть необходимость, он сверх редкая.

Именно сверх-редкая. Я ни применил ни разу (всегда обходился), многие мои коллеги (они работают с явой с самого начала) тоже. Они рассуждают так: нет хороших паттернов/гуд практисов на основе этих референсов, а есть с их отсутствием. Вот и делают с их отсутствием как умеют и делают годами. Я в сане работаю недавно, но знаю уже несколько хороших уважаемых инженеров. Они не используют эти референсы именно потому что у них не возникала в этом необходимость.

> В отличии от С++ это именно референс, а не объект создаваемый на стеке.

Да да, не забывайте - в яве указатели всегда кроме элементарных типов int, long, short, float, double, char и byte (может забыл кого, но это не важно).

>>> Быдлоподсчета быдлоссылок в мейнстримной Яве нет.

>>А, точно... там же Божественный Сборщик Божественного Мусора!

>Истерика продолжается. Еще один слив засчитан.

Да да .. похоже отрубился. Посмотрите историю: человек десять часов подряд почти без перерывов пытается доказать что ява говно :D даже я хотя и очень долго тут, но я хотя бы поспал часов 8..

> Истерика продолжается. Еще один слив засчитан.

Мой ответ конечно не по делу.

А вот по делу: я думаю, что и в плюсах возможен аналог явовского сборщика мусора через аналог shared_ptr, но не знаю его готовой реализации.

> Да да .. похоже отрубился.

Рано радуешься...

Re^2: Java полностью свободна под лицензией GPL

> ОО программы расходуют больше памяти чем обычные. кто по потреблению памяти вырывается вперёд? часто это именно C++ программы, а не Java.

Давай уже пример приведи, что ли. Ссылку на тест, где ява победно ест в 11-40 раз больше памяти, чем плюсы (про Си я уже молчу), я уже давал

>А вот по делу: я думаю, что и в плюсах возможен аналог явовского сборщика мусора через аналог shared_ptr, но не знаю его готовой реализации.

Только плюс зароется в безумных shared_ptr<> и код будет ТАК жутко выглядеть и пользоваться этим страшно неудобно. Да и реализации убогие.

Кстати, есть ведь майкрософтская штука, есть managed C++, так прикрутили .NET к сям, вот вам и сборка мусора и "безопасный" код, всё быстро.. если надо, можно использовать unsafe функции.. замечательно вроде.. что-то не вижу толп бегущих туда Java-девелоперов.

>А вот по делу: я думаю, что и в плюсах возможен аналог явовского сборщика мусора через аналог shared_ptr, но не знаю его готовой реализации.

В плюсах нельзя взять объект и попросить его перечислить тебе все внутренние указатели для трассировки. На codeproject.com я видел какое-то пионерское поделие, где грозились реализовать "generational garbage collector", но ни один вменяемый разработчик такое в реальный проект пихать не будет. BTW если бы я хотел gc в плюсах, я бы взял его из библиотеки с более-менее приличной репутацией, типа буста. Но в бусте его нет по понятным причинам - там надо препроцессор типа moc делать, который будет пихать в объект разметку под gc.

> Давай уже пример приведи, что ли. Ссылку на тест, где ява победно ест в 11-40 раз больше памяти, чем плюсы (про Си я уже молчу), я уже давал

Это вообще необоснованные высказывания что ява жрёт много памяти. JVM изначально сколько-то съест и всё. А дальше, сколько будешь выделять в своей проге, столько и будет расходоваться. Это всё разговоры. Примеров он не приведёт адекватных. У меня вот был раньше kopete, вроде маленькая болталка.. а жрала 200М (!). это же полный ППЦ. У меня огромная IDE столько ест, так она сколько всего делает и умеет.

>Кстати, есть ведь майкрософтская штука, есть managed C++, так прикрутили .NET к сям, вот вам и сборка мусора и "безопасный" код, всё быстро.. если надо, можно использовать unsafe функции.. замечательно вроде.. что-то не вижу толп бегущих туда Java-девелоперов.

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

так что уродец типа явы, и правильно что туда не бегут.

Re^2: Java полностью свободна под лицензией GPL

> А вот по делу: я думаю, что и в плюсах возможен аналог явовского сборщика мусора через аналог shared_ptr, но не знаю его готовой реализации.

Это называется Smart Pointer, и он выносит мусор, когда он не нужен, а не когда запускается сборщик мусора.

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

>так что уродец типа явы, и правильно что туда не бегут.

Значит уродец эту прогу писал. Значит он и не подозревал что юзер может всё включить. Просто так алгоритм поставлен. Это не проблема .NET'a.

Запомните: ни .NET, ни Java не являются панацеей от идиотизма и убогих программистов. С++ им тоже не сможет помочь. Разве что в случае C++ такие товарищи быстрее отваливаются, а на Java у них есть шанс что-то жалкое, но работающее написать (на managed C++ или C# тоже).

> В плюсах нельзя взять объект и попросить его перечислить тебе все внутренние указатели для трассировки.

Я думаю по-другому: меняться будет указатель внутри аналога shared_ptr, а объекты будут для перемещаться (т.е. копироваться-уничтожаться) на другое место. А за обычные указатели, если ты юзаешь, ты сам будешь отвечать, как в яве за слабый указатель.

Re^4: Java полностью свободна под лицензией GPL

> Это вообще необоснованные высказывания что ява жрёт много памяти. JVM изначально сколько-то съест и всё.

В том тесте JVM не учитывалась

Только в яве слабый указатель мало кому нужен (на практике вроде даже никому) и никто за него не отвечает.

> Значит уродец эту прогу писал.

Ну __невозможно__ такую простую прогу написать криво...

>Я думаю по-другому: меняться будет указатель внутри аналога shared_ptr, а объекты будут для перемещаться (т.е. копироваться-уничтожаться) на другое место. А за обычные указатели, если ты юзаешь, ты сам будешь отвечать, как в яве за слабый указатель.

Compacting gc мы пока не обсуждаем.

> В том тесте JVM не учитывалась

Значит так написано. Что написали, как запустили JVM, так и будет работать.

Я не видел методики теста, но вычесть расходы JVM не так то просто. Даже пустая прога при запуске уже имеет непустую кучу.

> Ну __невозможно__ такую простую прогу написать криво...

Это не вам судить, не вы её писали. Значит возможно, раз столько израсходовалось памяти неведомо на что, значит ресурсы расходовались бездумно.

> Compacting gc мы пока не обсуждаем.

А я как раз о нем задумался, когда кибергном счел, что я уснул...

А что может не хватать в shared_ptr? А, анализа достижимости вместо подсчета ссылок? Ну будем анализ проводить тоже ТОЛЬКО через эти наши указатели -- а то, что достижимо через обычный -- это как в яве слабый указатель.

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

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

>У меня вот был раньше kopete, вроде маленькая болталка.. а жрала 200М (!). это же полный ППЦ. У меня огромная IDE столько ест, так она сколько всего делает и умеет.

кстати да. раньше у меня она тоже жрала под 200 мб. так же хотел в пример привести, но сейчас проблема вроде решилась (не разбирался как).

Ну вот кажется вы предлагали перехватывать segfault, а теперь хотите юзать эти ваши жалкие ссылки чтобы анализировать достижимость. Вот случится у вас какой-то fault, и все ваши shared_ptr потеряются и не освободятся. То что вы предлагаете не является ни заменой, ни аналогом сборщику мусора в Java. То что вы предлагаете - это просто небольшая подстраховка.

Причём подстраховка совсем примитивная и то что вы предлагаете не идёт ни в какое сравнение с алгоритмом сборщика мусора в Java и тем более о GC который будет (точнее уже есть) в Java7. Кроме того, хотел бы я посмотреть как вы попляшете со своими shared_ptr в многопоточных приложениях. Вы либо будете всех стопорить, либо запутаетесь в них окончательно.

Чтобы отвечать на такого рода посты надо, видимо, написать робота, разговривающего в стиле Томми...

> как вы попляшете со своими shared_ptr в многопоточных приложениях

вопрос поставлен правильно и я думаю решаем тоже

> Чтобы отвечать на такого рода посты надо, видимо, написать робота, разговривающего в стиле Томми...

Напишите. Будет интересно. Будет сносная болталка - получете всемирную известность и прославитесь сами как Божественный Программист и прославите Божественные Кресты :)

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

Надо протирать глаза, прежде чем смотреть.
> unzip -l /usr/local/jdk1.6.0/jre/lib/rt.jar | grep "java/lang/Object.class"
     1475  06-07-08 12:50   java/lang/Object.class

>> как вы попляшете со своими shared_ptr в многопоточных приложениях

> вопрос поставлен правильно и я думаю решаем тоже

Я не сомневаюсь что решаем. Сборщики мусора это целая наука, а вы тут предлагаете по бырому на коленках переделать shared_ptr и добиться сборки мусора без сборщика мусора :)

> Надо протирать глаза, прежде чем смотреть.

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

> Я не сомневаюсь что решаем. Сборщики мусора это целая наука, а вы тут предлагаете по бырому на коленках переделать shared_ptr и добиться сборки мусора без сборщика мусора :)

Ну так осталось эту науку адаптировать и приложить...

> Напишите. Будет интересно. Будет сносная болталка - получете всемирную известность и прославитесь сами как Божественный Программист и прославите Божественные Кресты :)

Плюсы ужасны, но у них есть перспектива. У явы ее нет.

А прославлятся я лучше буду, написав че-нить типа плюсов.