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

Alexeis, 

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


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

Добавлено через 5 минут и 5 секунд
пусть I - интерфейс, obj - объект класса, реализующего интерфейс
выполнены следующие действия
I a = obj
I b = obj
I c = obj

где в этом случае расположен счетчик ссылок на obj? (в каждом из a, b, c?)

MAKCim, я сейчас не говорю про интерфейсы, как о преимуществе, это уже подробно изжевали в старой теме. Тут я говорю про то что механизм интерфейсов находиться в противоречии с механизмом стековых (не динамических) объектов, так как у последних время жизни от входа в блок до выхода. Подсчет ссылок должен реализовывать объект. Все интерфейсы наследуются от IUnknown, который требует реализации методов подсчета ссылок (поскольку эти методы в нем объявлены). Интерфейс сам по себе не является сущностью. Он не имеет ни каких данных, это лишь протокол доступа к объекту, на деле являющийся чем-то вроде дополнительной таблицы VMT, которая расположена в объекте. Это и есть гарантия того что объект исполняет интерфейс.

Добавлено через 1 минуту и 41 секунду

точнее в объекте указатель на нее.

вот за это я и люблю С++, можно создать такой класс, объекты которого нельзя создать в стке, а можно только в куче, и наоборот....
и никаких тебе разговоров о том, что концепция стековых объектов плохо сочетается с концепцией интерфейсов и подсчетом ссылок  

где ты нашел противоречие?
приведи пример



я правильно понимаю: класс, реализующий любой интерфейс, должен реализовывать методы подсчета ссылок?
если так, на лицо еще один показатель "гибкости"

Это сообщение отредактировал(а) MAKCim - 2.6.2008, 12:59

    Время жизни стековых объектов от начала блока, до конца, время жизни, время жизни объекта созданного по запросу клиента( т.е. переменной объекта нет вообще как таковой, получен только его интерфейс) не определенно. фиксированно != не определенно. 


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


  Это возможность для появления ошибок, зачем тебе лишняя возможность появления ошибок? Гораздо лучше когда компилятор тебе не даст сделать глупость переведя ошибку из времени исполнения во время компиляции. Это известный принцип. Самые лучшие ошибки это те которые видны на этапе компиляции, потом идут те которые кричат о себе в RunTime, а самые вредные, которые молчат и тихо делают свое черное дело.

да. типа CnPack или ModelMaker CodeExplorer. Впрочем, сам их не делал, потому не могу сказать наверняка, позволят ли они до компиляции неявно делать замену так, чтоб не надо было сохранять файл. 

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

в общем я не вижу никакой опасности

Добавлено @ 13:28

cтоп
реализации методов в интерфейсе быть не может
допустим у меня есть интерфейс I и класс C, реализующий I
где будет реализация подсчета ссылок?

Это сообщение отредактировал(а) MAKCim - 2.6.2008, 13:30

а я и написал про этап компиляции, если к примеру перегрузить для класса операторы new delete, и сделать их закрытыми, то объект можно будет создать только в стеке



причем достаточно сделать закрытой только одну форму оператора new(delete), в этом примере такое



не прокатит

Это сообщение отредактировал(а) Lazin - 2.6.2008, 13:34

Интерфейсы - это только COM?!

  Ничуть. Интерфейсы прекрасно работают безо всякого COMa, но они просто совместимы с COM. COM нужен только для межязыкового взаимодействия. При работе внутри приложения написанного только на VCL или приложение + Dll, COM не участвует, работают лишь встроенные механизмы.

А с чего тогда любой интерфейс должен наследоваться от IUnknown?

Lazin, я и не сомневаюсь, что на С++ можно написать Delphi, более того сам компилятор таки написан на билдере. Это все тонкие нюансы, которые не обязательно знать программисту на Delphi. У него есть хороший и главное ПРОСТОЙ инструмент, который много за него делает, причем делает скрыто. Это работает вне зависимости от того знает он что его объекты создаются в куче или не знает. В идеале ему вообще не нужно знать слова указатель. Программист Delphi должен проектировать программу при помощи паттернов, которые реализуются при помощи высокоуровневых средств ООП, которые работают стабильно. Важно не изобретать велосипедов, там где уже все поставлено на поток.

Alexeis, 
ответь на мой вопрос

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

Добавлено через 2 минуты и 40 секунд
MAKCim, я уже писал, что интерфейс не самостоятельная сущность. Сам он ничего не умеет. Подсчет ссылок целиком и полностью лежит на объекте.