Есть ли будущее у DELPHI?

Shaggy, еще раз. Основная проблема, которую я тут вижу, заключается в том, что ссылка с подсчетом ссылок и без зависит от места в иерархии. Это маразм. Я хочу общаться со своим объектом в одном месте как с объектом одного класса/интерфейса, а в другом - как другого. И это нормально для ООП кода. При чем тут вообще посчет ссылок?
При этом в С++:
T * - невладеющий указатель
unique_ptr<T> - уникально владеющий указатель(т.е. является единственным правомерным владельцем)
shared_ptr<T> - множественное владение(подсчет ссылок)
weak_ptr<T> - не владеет объектом, но позволяет получить shared_ptr(нулевой, если объекта уже нет)

Вне какой-либо зависимости от иерархий, "вида" типа(класс или примитив) и пр.

Цитата Shaggy @ 14.07.14, 19:36

с чего вдруг?

D_KEY, korvin, я не понял, мы с кем разговариваем?

Цитата Qraizer @ 14.07.14, 18:20

Никто не владеет, некому и считать ссылки. Отсюда в частности и обсуждаемые проблемы.

Не надо считать? Ну ладно, а зачем тогда было вводить счётчики? Ах, всё-таки надо... тогда почему такую простейшую задачу надо выполнять руками? На кой хрен сдался этот интерфейс, который не умеет того, для чего создавался - избавить программера от рутины?
Не, это явно бред сивой Абракадеро, выдуманный специально по такому случаю взятым в аренду у MS-а системным архитектором-профессионалом по эффекту Балмера.

Цитата Qraizer @ 14.07.14, 19:07

Не ну Дельфи-то понять можно, korvin. Унаследовав COM к себе и приняв его вынужденные ограничения, Дельфи с COM-интерфейсами иначе никак и не поступить.

Интересно, как эти их интерфейсы теперь уживаются с Objective-C фрейворками например, где ARC считает объекты, а не интерфейсы.

Добавлено 15.07.14, 03:34

Цитата Shaggy @ 14.07.14, 19:36

а служебные методы уже реализовали за тебя

Которые мне придется переопределять, как в твоем TNoRefObject.

Цитата Shaggy @ 14.07.14, 19:36

а вообще, хранить и использовать две ссылки(с подсчётом ссылок и сырую) на одну сущьность, это нормально?
C++way?

Ну Делфи-то это позволяет:

var NoCount: TInterfacedObject;
NoCount := TInterfacedObject.Create;
 
procedure Foo(Countable: IInterface);
procedure Bar(NoCount: TInterfacedObject);
 
Foo(NoCount);
Bar(NoCount);

и даже никаких варнингов или хинтов, только Access Violation. =)

Цитата Shaggy @ 14.07.14, 19:36

TObject, пустее просто нет

Это не интерфейс.

TInterfaceA = class(TObject)
  ... // abstract methods
end;
TInterfaceB = class(TObject)
  ... // abstract methods
end;
TMyClass = class(TObject, TInterfaceA, TInterfaceB) // Oops!

У делфистов какое-то альтернативное понятие пустоты:

Цитата Shaggy @ 14.07.14, 19:36

и?

Что "и?" Либо считайте ссылки объекта, либо не уничтожайте объект при значении счетчика == 0. Отсутствие интерфейсных ссылок на объект не означает отсутствия "классовых" ссылок на объект.

Сообщение отредактировано: korvin - 15.07.14, 03:55

Цитата Shaggy @ 14.07.14, 16:45

function TNoRefObject._AddRef: Integer;
begin
Result := MAXINT;
end;

function TNoRefObject._Release: Integer;
begin
Result := MAXINT;
end;

Эти две реализации должны подставляться автоматически компилятором, а не программистом. А пока оно так , как оно есть в Delphi, люди будут пользовать Java/C# где таких граблей нет.

Ну в java/c# вообще сборщик мусора. Правильно сравнивать с C++, objective-c и др. языками с ручным управлением памятью и подсчётом ссылок.

D_KEY, тут скорее всего сравнение в логике поведения ключевого слова interface. В Java и ссылки через-интерфейс и через класс приводят к одинаковым последствиям:

SomeClass someObject = new SomeClass();
InterfaceThatIsImplmentedBySomeClass someInterfacedObject = someObject;
 
// Количество ссылок на someObject = 2

В Delphi подсчет ссылок ведется только для интерфейсов:

var
someObject: SomeClass;
someInterfacedObject: InterfaceThatIsImplmentedBySomeClass;
begin
someObject := TInterfacedObject.Create;
someInterfacedObject := someObject;
 
{ Количество ссылок на someObject = 1 }

Такая вот петрушка.

Цитата D_KEY @ 15.07.14, 07:20

Правильно сравнивать с C++, objective-c и др. языками с ручным управлением памятью и подсчётом ссылок.

Rust?

Цитата korvin @ 15.07.14, 09:15

Цитата D_KEY @ 15.07.14, 07:20

Правильно сравнивать с C++, objective-c и др. языками с ручным управлением памятью и подсчётом ссылок.

Rust?

Ну там как и в плюсах отдельные типы ссылок.

Цитата korvin @ 15.07.14, 03:16

Интересно, как эти их интерфейсы теперь уживаются с Objective-C фрейворками например, где ARC считает объекты, а не интерфейсы.

Не знаю. Там, видимо, один в один архитектуру COM не проксили.

Добавлено 15.07.14, 11:08
korvin, а что такое ARC?

Цитата Qraizer @ 15.07.14, 11:07

korvin, а что такое ARC?

Оно. Компилятор проставляет retain/release по тем же правилам, по которым их люди писали руками.

Сообщение отредактировано: MyNameIsIgor - 15.07.14, 11:27

Хм, а это случаем не то, что добавили в C++11 как поддержку сборщиков? Надо полистать, что там писали, а то в Стандарте эти GC упомянуты очень скупо.

Цитата Qraizer @ 15.07.14, 11:50

Хм, а это случаем не то, что добавили в C++11 как поддержку сборщиков? Надо полистать, что там писали, а то в Стандарте эти GC упомянуты очень скупо.

Нет, не то. И там нечего описывать - просто функции для подсказок возможному GC.

Ну вот их-то я и видел. Т.е. никакой другой инфы не предлагалось до 11-го года?

Цитата Qraizer @ 15.07.14, 15:26

Ну вот их-то я и видел. Т.е. никакой другой инфы не предлагалось до 11-го года?

Ну, вроде видел предложения опционального GC от Hewlett Packard, но какие-то странные...
А то, что сейчас в Стандарте, не понятно как юзать, т.к. ни одной реализации с GC нет.

Да будет ли большой толк от GC в C++? Деструкторы-то никуда не денутся. Разве что для некоторых алгоритмов удобнее будет.