Держи ты этого хотел? Конечто это произойдет не в момент потери последней ссылки - но все что ты паречислил оно делает. Since 1.2.

import java.lang.reflect.*;
import java.lang.ref.*;

public class Test {
public static void main(String[] args) {
SocketFactory factory = new SocketFactory();
ISocket socket = factory.connect("localhost",80);
socket.write("Hello");
socket.write("Hello");
socket.write("Hello");
socket = null;
}
}

class SocketFactory extends Thread implements InvocationHandler {
MySocket socket;
ReferenceQueue queue = new ReferenceQueue();
ISocket connect(String host, int port) {
socket = new MySocket();
ISocket proxy = (ISocket)Proxy.newProxyInstance(this.getClass().getClassLoader(),new Class[]{ISocket.class}, this);
WeakReference ref = new WeakReference(proxy, queue);
ref.enqueue();
start();
return proxy;

}
public void run() {
try {
System.out.println("waiting");
queue.remove();
socket.close();
}catch(Exception e) {
throw new RuntimeException(e);
}
}

public Object invoke(Object proxy, Method method, Object[] args) throws Exception{
return method.invoke(socket, args);
}
}

interface ISocket {
void write(String string);
void close();
}

class MySocket implements ISocket {
public void write(String string) {
System.out.println(string);
}
public void close() {
System.out.println("closed");
}
}

Ну вообщем функциональность аналогична. Но в твоем примере есть два э-э недостатка: 1. метод вызывается через reflection - явно не самый быстрый способ (или может в Java reflection эффективно реализовано?) и как следствие работа выполняемая компилятором C++ при разрешении перегрузки оператора -> выполняется в runtime. 2. используется дополнительная нить.

При этом в C++ для реализации умных указтелей используется всего лишь перегрузка оператора -> и шаблоны (далеко не изощренное их использование - одно из простейших).

Так что в возможностях compile-time Java серьезно проигрывает C++ - никаким метапрограммированием там и не пахнет (к сожалению).

И еще вопрос: можно ли в Java с помощью reflection организовать поиск метода по имени во время выполнеия программы, при этом имя может быть произвольным, т.е. как Objective C: NSObject* o = some_fun(); [o mySuperDuperMethod]; при этом естесвенно mySuperDuperMethod не объявлен в классе NSObject.

И последнее: можно ли с помощью reflection добавлять методы к существующим классам, как с помощью категорий в Objective C?

> метод вызывается через reflection - явно не самый быстрый способ

Дети ну сколько можно. РЕфлективный вызов метода по скорости аналогичен обычному. Домашнее задание тебе написать тест.

2. используется дополнительная нить

И что? Одна нитка проста в реализации дополнительных либ не требует затраты на современных машинках смешные. ДА сановцы пакостники не реализовали листенера - надо висеть и дожидаться.

> При этом в C++ для реализации умных указтелей

Вся вигня в том что в C++ без них жизнь - это страдание, а в Java они не нужны кроме достаточно редких случаев в которых и руками работа не большая.

> можно ли в Java с помощью reflection организовать поиск метода по имени во время выполнеия программы

да

> можно ли с помощью reflection добавлять методы к существующим классам

только не с посощью reflection. See for Javassist at JBoss.org.

Что-то не работает. Зачем ты сразу enqueue делаешь? Получается, что он сразу в очередь попадает и его тут же закрывают. Правда, без enqueue оно вообще висит.

По идее, после того, как останется только слабая ссылка (т.е после завершения main), эта ссылка должна встать в очередь, откуда ее и подметут после queue.remove(). Но почему-то у меня висит и визуально ничего не делает. Пробовал System.gc() вставлять - никаких результатов.

В чем проблема? И вообще, правильно ли я механизм понял?

Ага, кажется понял. .enqueue вызывать не надо. Но! При этом если WeakReference умрет раньше, чем его дите (что, похоже, и происходит в данной ситуации), то он не попадет в очередь (так как WeakReference не становится cleared - дите еще не определилось как weak-referencable).

капец. прочитал этот опус. неужели после всех этих условностей, "слабых ссылок" и етц. кто то будет утверждать что жава проще и удобнее

Она проще для того круга задач, для которого она предназначена. Java - это почти что Domain Specific Language.

> РЕфлективный вызов метода по скорости аналогичен обычному.

Рефлективный вызов метода добавляет как минимум еще один уровень косвенности - это не может по скорости сравниться с call или встраиванием функции.

> Вся вигня в том что в C++ без них жизнь - это страдание, а в Java они не нужны кроме достаточно редких случаев в которых и руками работа не большая.

Вся фигня в том, что и для С/C++ сборщики мусора (см. http://www.hpl.hp.com/personal/Hans_Boehm/gc). Только они не являются частью языка.

Ну а насчет "не большой работы" - сравните:

template <typename T>
class DefaultInvocationHandler
{
  T* ptr;
public:
  DefaultInvocationHandler(const T* ptr) : ptr(ptr) 
  {
    // можно сделать что нибудь перед вызовом любого метода
  }

  ~DefaultInvocationHandler()
  {
    // можно сделать что нибудь после вызовом любого метода
  }

  T* operator-> ()
  {
    return ptr;
  }
};

template <typename T>
class DefaultObjectCreationHandler
{
public:
  static T* create() { return new T; }
  static void destroy(T* x) { delete x; }
};

template 
<
  typename T, 
  typename ObjectCreationHandler = DefaultObjectCreationHandler,
  typename InvocationHandler = DefaultInvocationHandler
>
class smart_ptr : public ObjectCreationHandler,
                  public InvocationHandler
{
  T* ptr;
public:
  smart_ptr(const T* ptr) : ptr(ptr) { }
  ~smart_ptr()
  {
    ObjectCreationHandler::destroy(ptr);
  }

  InvocationHandler<T> operator-> ()
  {
    if (ptr == 0) ptr = ObjectCreationHandler::create();
    return InvocationHandler<T>(ptr);
  }
};

В приведенном примере можно с помощью стратегий управлять созданием/уничтожением объекта и определять действия выполняемые до/после вызова метода или обращения к полю объекта. Кроме того если стратегии определяют дополнительные функции, они тоже будут доступны.
При этом выполняется статический контроль типов - нет ни одного приведения типов в отличие от примера на Java, при том, чтьо данный указатель будет работать с произвольным типом данных.

Для чего в приложении на жабе может понадобицца щёччик сцылок?

А зачем Вы от ObjectCreationHandler и InvocationHandler пронаследовались?

Дети ну сколько можно. РЕфлективный вызов метода по скорости аналогичен обычному

>Дети ну сколько можно. РЕфлективный вызов метода по скорости аналогичен обычному

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

>Одна нитка проста в реализации дополнительных либ не требует затраты
Особенно если она реализуется через отдельный процесс, как тут кто-то выше писал :)

Насчет чего могут smart-pointers, чего не может ява: пример - напишите код, который неявно делает некие действия при добавлении ссылки на объект.

class A
{ public void OnNewReference() {} };

A a0, a1 = new A;
a0 = a1; // Здесь должна вызываться OnNewReference

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

smart_ptr<T, MyCreationHandler, MyInvocationHadler> p(...); p->method_of_the_T_class(); p.helper_method_from_MyCreationHandler(); p.helper_method_from_MyInvocationHadler();

Вот так.

Дети ну сколько можно. РЕфлективный вызов метода по скорости аналогичен обычному

Понятно. Интересный прием :)

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

>Держи ты этого хотел

НееееееТТТ!!!! Я сейчас заплачу! Иди, меняй ник, а то засмеют! ГУРУ МЛЯ! Ты не жАБА-гуру - ты жОПА-гуру!

>0 = a1; // Здесь должна вызываться OnNewReference

НЕЕЕЕТ! Не туда акцент!!! При уничтожении объекта должен быть вызван метод некоторый! И не в "обозримое время" когда ГЦ эахочет, да потом очередь финализации дойдет, а НЕМЕДЛЕННО!!! ПОСМОТРИТЕ ГОСПОДА ГУРУ - подосиновые на SWT, изучите как там сделано управление ресурсами, ну а если не допрет попробуйте освобождать например DC в finalize и ОФИГЕЙТЕ от результата (по крайней мере в виндах). ПОЧИТАЙТЕ ВАШЕГО БОГА Гослинга и почитайте, что он говорит об использовании finalize для управления ресурсами! finalize - это не ДЕСТРУКТОР МЛЯ! ВОТ ТАК гОСПОДИН r!!!

И еще ребята вроде Dmt - не стоит спорить с упертыми типа r, или vtVitas - неужели приятно смотреть как они в конечном итоге обсираются? Ведь этот r даже и не вьезжает о чем речь то идет ...

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

Тогда перепишет smart_ptr::operator-> ():
InvocationHandler<T>& operator-> () // <-- ссылка
{
    if (ptr == 0) ptr = ObjectCreationHandler::create();
    return *this; // на подобъект
}

Дети ну сколько можно. РЕфлективный вызов метода по скорости аналогичен обычному

>НЕЕЕЕТ! Не туда акцент!!! При уничтожении объекта должен быть вызван метод некоторый! НЕМЕДЛЕННО!!!

Согласен, я об этом уже говорил. Просто ясно, что это принципиально невозможно сделать в языке с GC типа явы. Чего тут спорить :)

> Насчет чего могут smart-pointers, чего не может ява: пример -
> напишите код, который неявно делает некие действия при добавлении
> ссылки на объект. 

Ключевое слово "неявно".

Когда принимаешь участие в проекте где 2 гига legacy кода
(абсолютно недокументированного), написанного несколькими
поколениями разработчиков, часть из которых толком даже
незнали симантику языка, то кроме знания языка и его API
приходиться изучать тысячи вот таких вот неявностей, чтобы
хотябы понимать его в общих чертах.

В enterprise приложениях таких вот неявностей или не должно
быть совсем или должно быть минимум и полностью документированно.

Надеюсь своим замечанием я тут никого не оскорбил?

Дети ну сколько можно. РЕфлективный вызов метода по скорости аналогичен обычному

Неявно для клиента, конечно же. Просто странно: адепты явы описывают яву, как супер объектно-ориентированный язык, при этом как один протестуют против широкого применения основного столпа объектно-ориентированного дизайна - инкапсуляции :)
Ведь проблема в том, что запись типа:
a0 = a1;
a0.OnNewReference();
приводит к усложнению контракта класса и гарантирует, что когда-нибудь, кто-нибудь таки забудет написать именно так, а по коду найти такую проблему в огромном проекте практически невозможно.

Дети ну сколько можно. РЕфлективный вызов метода по скорости аналогичен обычному

Вдогонку

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

По мне так куда проще написать небольшой документ на несколько страничек, где описывается, какие типы "интеллектуальных" указателей использовать в каждой возможной ситуации (которых не так уж и много), какие возможны проблемы (типа циклических ссылок) и пути их решения. Чем для каждого класса писать длинные пояснения типа: как только у класса A добавилась ссылка, вы должны для старой ссылки вызвать метод OnReleaseReference, а для новой OnNewReference и т.д. и т.п. Что уж тут простого и понятного - не пойму :)

Я так пологаю данный функционал можно реализовать в ООП стиле c
применением шаблона factory (хоть на Java хоть на C++).А не
заморачиваться, перегружая оператор присвоения. Поправь, если
я не прав.

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

Так вот в этом контексте, я выбираю инструмент без недокументированных возможностей - тот в котором код сам и является документацией. Мне так легче.

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

Тогда стройными рядами к дядюшке Билли!

>Я так пологаю данный функционал можно реализовать в ООП стиле c
применением шаблона factory

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

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

Тогда стройными рядами к дядюшке Билли!

>Мне ещё не разу в Java не было нужды отслеживать владение объектом. А если бы нужно было бы применил бы шаблон "делегат"
Каким образом, если не секрет?

Инкапсуляция рулез

Инкапсуляция без сомненья есть гуд, но проблемка в том, что на С++ написать действительно 100% инкапсулированный смарт-пойнтер невозможно.
Ок - перегрузили operator->(), но где-нибудь обязательно всплывёт, что надо передавать объект по ссылке, так что надо ещё перегружать и operator*(), а это уже означает, что кто-нибудь сможет вытащить из смарт-пойнтера исходный голый пойнтер, да ещё и неровен час сохранить его где-нибудь, и тогда весь сей красивый дизайн теряет всякий смысл.

Народ! Ну сколько можно! Пишите на Delphi и будет всем счастье!

Тогда стройными рядами к дядюшке Билли!

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

Все-время слушу/читаю этот довод и просто не понимаю, какой у человека должен быть уровень интеллекта (не говоря уже о профессиональном), чтобы сохранить голый пойнтер, взятый неизвестно откуда. Это уже из области клиники :) Любой нормальный человек, при взгляде на модуль, который возвращает голый указатель тут же ищет метод типа FreeRawPointer() (или типа того), если такого метода нет - то значит этот указатель можно использовать в том же блоке кода, где и получение, причем он валиден до вызова любой неконстантной функции класса. Если же можно и нужно возвращаемый указатель где-то сохранять, то возвращается уже обернутый указатель. Все достаточно очевидно и с опытом делается автоматически. Конечно, иногда и GC был бы полезен, кто спорит? :)

Кыш отседа! Тут идёт холивар JAVA vs C++

Тогда стройными рядами к дядюшке Билли!

>Народ! Ну сколько можно! Пишите на Delphi и будет всем счастье!

Согласен, замечательный язык - объектная модель подозрительно похожа на яву, но проблем с GC - нет. Это очень удобно, сам на нем много программировал :)

В общем, всем спасибо за интересную дисуссию - я многое осознал и для себя выводы сделал :)

И тебе спасибо!

Хороший  и коректный собеседник редок на lor :)

В догонку я так понимаю, что если управлению сущностью сложно то его
нужно выносить в отдельную сущность... ЭЭЭ

Всё .. умолкаю ... умлокаю

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

А ты слычайно не заметил скорость развития желдеза? Или по твоему удлиннять разработку дешевле чем апгрейд железа? Даже микрософт так не считает.

> // Здесь должна вызываться OnNewReferenc

Я тебе 44,5 примеров таких придумаю. Придумай реальную задачу в которой такое нужно. А таких хреней напридумывать много можно. Давай пиши на C софт который работает под MacOS9/X, xNIX, Windows и прочая херня. Развлекайся со своими смарт поинтерами.

> И не в "обозримое время" когда ГЦ эахочет, да потом очередь финализации дойдет, а НЕМЕДЛЕННО!!!

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

> finalize - это не ДЕСТРУКТОР МЛЯ

Твою мать - я гдето говорил что это деструктор? Мне нахер не впираеться автоосвобождение ресурсов - меня не заламаяет вызвать close() в finally руками. Если ты тупой и читать нихера не научился - так изобретая на свою жопу дальше несуществующие проблемы и ищи элегантные методы их решения.

> приводит к усложнению контракта класса и гарантирует, что когда-нибудь, кто-нибудь таки забудет написать именно так

Млять ты можешь вместо плюса поставить минус и что? Давай еще обсудим проблему обмена значениями регистров на Java/.NET. Если единственная твоя самая большая проблема в разработке это считать ссылки - иди играйся в своей песочнице дальше, и оттачивай сие искуство, пока не станешь гуру-подсчета-ссылок.

> Это уже из области клиники :)

Вот - одна из умных твоих фраз. Голову надо лечить не смартпоинтерами.

Ну и для чего ты столько понаписал? Мог бы сказать короче: "Жаба - рулез, а вы все - негодяи". И заплакать...

> Мог бы сказать короче

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

> Ты дурачек

Пишется "дурачок". Пока.

>Вот - одна из умных твоих фраз. Голову надо лечить не смартпоинтерами.

Забей на него он и вправду дурачок. Ни когда ещё не было проблем с освобождением ресурсов после System.gc(); System.gc(); System.gc(); :). Кстате, как я понимаю, в .Net та же порнография. Всё что можно добиться применением перегрузки операторов, можно построить на стандартных ООП шаблонах программирования типа фабрики и т.п. Не так эффективно, но зато потом не паришься с разбором кода (живой пример, перегрузка [] как векторного произведения, а это ещё не самый жуткий пример), а быстро разбираешься в коде и продолжаешь работать.

Признак крутости - это системный подход, архитектура и дизайн приложения

Не хотел отвечать - но не удержался. Вы все-таки определитесь: 'порнография' или 'не было проблем'? :) Ладно, каждый останется при своем мнении - я для себя выводы сделал.

>Не хотел отвечать - но не удержался. Вы все-таки определитесь: >'порнография' или 'не было проблем'? :) Ладно, каждый останется при >своем мнении - я для себя выводы сделал.

Это порнография, которая на вид уёбищна и которая ни чего не гарантирует, но с которой ещё ни разу проблем не возникало ни у меня, ни у других (кого я знаю) кто с этим сталкивался.