Ладно, скажем по-вашему - почему в дельфях нету интерфейсов для неавтоматических объектов?

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

кстати, тебя не напрягает тот факт, что смарт-понинтеры в "неуправляемом" С++ надо указывать явно? как же? это же лишний код! почему надо писать лишний код?! или любые указатели в С++ становятся "умными" по умолчанию?

Добавлено через 4 минуты и 14 секунд

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

Добавлено через 7 минут и 4 секунды

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

Не, не напрягает. Я просто пишу boost::shared_ptr<MyType> (подставить tr1 по вкусу). А любые нет - указал, стали. Но никто не заставляет, чтоб они ими были.


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

ЗЫ Блин, мне надоедает обсуждать одну тему  

странно, что тебя не напрягает сам факт принудительного наследования от класса(TObject), у которого с полтора десятка методов. типа, "а вдруг я захочу реализовать собственную логику метода inheritsFrom(AClass: TClass)?" и т.д..

Добавлено через 1 минуту и 32 секунды
вообще, не могу понять. тебя не устраивает:
а) необходимость самостоятельно писать код в случае "косого наследования"?
б) необходимость реализации подсчета ссылок в том или ином виде?
в) необходимость реализации чего бы то ни было?

  Объект который управляет интерфейс не является автоматическим. Автоматическим объектом называется сам интерфейс (объект в общем смысле этого слова, не тот что инстанцируется классом).

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


Я понимаю. Только это костыль. Во-первых, я всё равно что-то должен писать (что мне вовсе не надо), а во-вторых, это как раз может создать потенциальные проблемы. Кто-нибудь будет юзать этот TMyMyObject, увидит, что он реализует IUnknown (который как я понял объявляет лишь всё, связанное с подсчётом ссылок) и решит, что это работает. А ему - обломись  Я ничего против подсчёта ссылок, даже его ручной реализации не имею - ну пусть будет отдельный интерфейс, который мы реализуем, если хотим. А не хотим - не будем 


Ладно, чо-т я запутался  Вопрос я переформулировал выше. Сорри, если что-то в вашей терминлогии не так понял 

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

Блин, у меня есть интерфейс объекта, поддерживающего, например, сравнение (IComparable  ) - зачем мне плясать с подсчётом ссылок?

Кстати, возникла идея - а в Delphi .Net интерфейся тоже наследуются от IUnknown?!

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

<указатель на управляющий объект>  -> <управляющий объект> -> <объект>

Фактически указатель на объект не доступен, доступен только <указатель на управляющий объект>, сам же <управляющий объект> реализует IUnknown и возможно еще кучу всякой хрени. При проходе очередного цикла сборки мусора объект перемещается в памяти и в управляющий объект записывается новый адрес объекта (существует системная очередь хранящая все ссылки на управляющие объекты), при этом <указатель на управляющий объект> остается неизменным. На управляющий объект может быть множество ссылок, которые он сам считает. Когда этот счетчик становиться равным нулю, объект будет объявлен не нужным и будут удален при следующем цикле сборки мусора.

Ну... это не банальный подсчёт ссылок. Насколько я знаю, ВМ просто хранит информацию о всех объектах и при запуске собрки мусора стоит граф объектов. "Висячие" части (не связанные со статическими полями, локальными переменными и т. д.) удаляются. То есть, это явно не подсчёт ссылок и реализуется это не на уровне отдельных классов (и не на уровне System.Object), а на уровне ВМ.


Он ничего не считает. Весь подсчёт проводится не во время работы, а во время сборки мусора.


Гм. А что это за IInterface?! Что в нём объявлено? Просто речь о том, что дотнетовские интерфейсы ни от чего не наследуются (что логично) - как с этим поступает Delphi .Net?

Это сообщение отредактировал(а) Любитель - 3.6.2008, 17:51

Alexeis, 
в общем с подсчетом ссылок ересь какая-то получается
как сказал Любитель, костыль на пустом месте

ты вот лучше скажи: как в Delphi обстоят дела с шаблонами?   

MAKCim,

шаблоны это не проблема языка... это проблема среды... 

нет, это проблема языка  

с шаблонами ясно   
сейчас найдем еще что-нибудь...

ну да. как же. писать малопонятные инструкции с <> - это запросто. А воспользоваться расширением для рефакторинга, которому надо будет передать имя класса и имя дл поля, и IDE  сформирует "скелет" по шаблону "Observer" - это не круто. аааа.... укусите меня за ногу....
Как в С++ с метаклассами дела обстоят?