> Умные указатели позволяют переложить эту работу с программитса на компилятор.

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

Можно и без try / finally и причём при исключении ничего не потеряется, просто писать нужно правильно.

Читаем про java.lang.ref:
http://www.javaportal.ru/java/articles/referenceclasses.html

1) Так что всётаки делает smart pointer?
2) Что в свете прочитанного может smsrt pointer, чего не могут reference классы?

> можно запретить создание объектов с помощью new - только с
> использованием специальных статических функций класса, возвращающих
> умный указатель

class A {
public static int refCounter;
private A() {
synchronized(A.class) {
if (refCounter) {
// Открыть COM port
}
refCounter++;
}
}
public void finalize() {
synchronized(A.class) {
refCounter--;
if (refCounter == 0) {
// Отпустить COM port
}
}
}
public static A getInstance() {
return new A();
}
public void push(int value) {..}
public int pop() {..}
}
работа будет в виде
void performSomeWork() {
A a = A.getInstance();
while(true) {
// А нам насрать, что тут будет Exception
a.push(a.pop());
}
}
В это случае, если все ссылки на экземпляры класса A будут потеряны и произойдёт FullGC, то ресурс COM порат будет отпущен.
Если же мы снова начнём плодить объекты то он снова будет открыт.

Что такого ещё может предложить Smart Pointer?

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

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

> Что такого ещё может предложить Smart Pointer? Предсказуемость - ресурс будет освобожден когда уничтожается указатель, а он уничтожается при завершении блока, в котором объявлен указатель. А в Java нужно ждать пока GC удосужится освободить объект.

Держи ты этого хотел? Конечто это произойдет не в момент потери последней ссылки - но все что ты паречислил оно делает. 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 та же порнография. Всё что можно добиться применением перегрузки операторов, можно построить на стандартных ООП шаблонах программирования типа фабрики и т.п. Не так эффективно, но зато потом не паришься с разбором кода (живой пример, перегрузка [] как векторного произведения, а это ещё не самый жуткий пример), а быстро разбираешься в коде и продолжаешь работать.

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

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

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

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