Форум на Исходниках.RU

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

jack128 — Thu, 28 Aug 2014 08:07:44 +0000

jack128: Хотя нет, напрямую прям дин массив нельзя использовать. Нужно просто IValueData не через наследование от TINtefacedObject реализовывать, а напрямую VMT интерфейса задавать, как они в System.Generics.Defaults компараторы реализовывали. Одно выделение дин памяти для любого managed типа необходимо.

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

jack128 — Tue, 26 Aug 2014 12:21:46 +0000

jack128:

Цитата korvin @ 26.08.14, 10:08

Или 8. Абракадабра ж осилила x64?

ну да. SizeOf(Pointer).

Цитата korvin @ 26.08.14, 10:08

Т.е. указатель на структуру.

указатель на структуру указателем быть не перестает.

Цитата korvin @ 26.08.14, 10:08

Как минимум TValue должен хранить идентификатор типа, допустим он int32

SizeOf(Pointer)

Цитата korvin @ 26.08.14, 10:08

возможно под указатель просто единообразно выделяется 8 байт независимо от платформы.

Нет.

Цитата korvin @ 26.08.14, 10:08

Т.о. получаем 12 байт на указатель + id типа.

нет, нет. Вообще в этом TValue small buffer optimization даже кой какая есть. Но она не работает для managed типов(для строк в частности).

Цитата korvin @ 26.08.14, 10:08

Но это лишь гипотеза.

абсолютно неверна.

-----

Вообще вот что они сделали, и как оно должно было быть сделано:

1) Понятно что для каких то типов нам по любому понадобится дин память. При этом хочется чтобы пользователю при работе с эти TValue не пришлось эту память освобождать ручками. Значит нам нужно поле интерфейсного типа.
2) Хоцца small buffer optimization. Чтоб всякие инты не требовали дин память. Желание похвальное.
3) Должно поддерживаться хранение managed типов (строк, интерфейсов, дин массивов и тд. Все типы, память за которыми компилятор убивает).

OK, ребята сделали так (код схематичный и сильно упрощен) :

TValue = record

private

FTypeInfo: PTypeInfo; // "id" типа, как ты выразился.

FValueData: IValueData; // тут сидят данные, которые только в дин память влазят

FSmallBuff: array[0..12] of byte;

public

...

end;

Ну вроде все нормально, как и должно быть. Но реализация - это швах.
1) SBO не работает для managed типов. Варианты, строки, интерфейсы и даже рекорды без managed полей - все в пролете. С чего такое ограничение - непонятно.
2) IValueData наделен лишней функциональностью, которая требует PTypeInfo. В результате хранятся две копии этого поля: первая в самом TValue, вторая в реализации IValueData. Хотя по идее это должен быть тупо кусок дин памяти, который освобождается при обнулении счетчика ссылок.
3) Вообще реализация IValueData.

type

TValueDataImpl = class(TInterfacedObject, IValueData)

private

FTypeInfo: PTypeInfo;

FData: TArray<Byte>; // тут хранятся дин данные.

public

FData - это дин. массив. Он сидит в дин памяти. TValueDataImpl - тоже в дин памяти. Зачем нужно два выделения памяти??
Наследование от TInterfacedObject: вообще не нужно. Объекты в дельфи держат 2 указателя(один под VMT, второй под монитор, который вообще нафиг никому не сдался). + каждая реализация интерфейса добавляет еще по SizeOf(Pointer) на инстанс объекта. Зачем все это в данном случае ??

Нужно то всего лишь заменить IValueData на самый обычный динамический массив. Который там и так содержит счетчик ссылок, сам освобождается когда надо.

вобщем я бы данные так хранил

TValue2 = record

private

FTypeInfo: PTypeInfo; // "id" типа, как ты выразился.

FHeapData: TArray<byte>; // тут сидят данные, которые только в дин память влазят

FSmallBuff: array[0..12] of byte;

public

...

end;

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

korvin — Tue, 26 Aug 2014 10:08:03 +0000

korvin:

Цитата jack128 @ 26.08.14, 09:32

(в дельфе это указатель, 4 байта)

Или 8. Абракадабра ж осилила x64?

Кроме того, я так понимаю, что строки в делфи все-же посложней (они разве длину не таскают с собой)? Т.е. указатель на структуру.
Как минимум TValue должен хранить идентификатор типа, допустим он int32, возможно под указатель просто единообразно выделяется 8 байт независимо от платформы. Т.о. получаем 12 байт на указатель + id типа.

Вторые 28 байт возможно сами данные типа string. Именно значения, хранящего размер строки, возможно еще какую-то служебную информацию (ведь под string'ом может скрываться и AnsiString, и WideString вроде) + указатель уже на сам массив байтов строки.

Но это лишь гипотеза.

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

jack128 — Tue, 26 Aug 2014 09:32:34 +0000

jack128: Блин. Есть в дельфе такой тип TValue. Что то типа boost::any, тип позволяющий хранить в себе значения любого типа.
Так вот, для того что сохранить строчку (в дельфе это указатель, 4 байта) этот тип выделяет 2 блока дин памяти, один в 28 байт, другой в 12. Вот скажите, это нормально???

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

trainer — Sun, 27 Jul 2014 09:15:30 +0000

trainer:

Цитата Shaggy @ 16.07.14, 15:32

Имелось в виду: какой язык?

Васик. Но сами сервера COM первоначально написаны преимущественно на C.

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

Qraizer — Thu, 17 Jul 2014 09:16:09 +0000

Qraizer: Т.е. передача параметром. А присваивание? Или метод есть для этого?
D_KEY, как думаешь, в ссылочной семантике ещё что-нибудь нужно? Вот к примеру в массив если такие положить.

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

jack128 — Wed, 16 Jul 2014 17:47:46 +0000

jack128:

Цитата Qraizer @ 16.07.14, 16:54

jack128, получается .Value. -- это аналог ->, да?

да.

Цитата Qraizer @ 16.07.14, 16:54

А счётчики по каким правилам будут меняться? В смысле, что их меняет?

там внутри сидит интерфейс. Его реализация и считает ссылки.

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

korvin — Wed, 16 Jul 2014 17:14:19 +0000

korvin:

Цитата jack128 @ 16.07.14, 16:31

Не, в дельфе вполне можно реализовать подсчет ссылок внешним по отношению в объекту способом. Будет не так удобно, как shared_ptr (в первую очередь из-за невозможности переопределить оператор вызова метода), но жить можно.

Это, понятное дело что можно. Другое дело, что нельзя отвязаться от существующего.

Цитата Shaggy @ 16.07.14, 16:35

ну вот microsoft не постеснялась "подменить понятия"

А они редко этого стесняются. Это показатель? Впрочем у MS так весьма существенная доля рынка, "можно" выпендриваться. У Эмбаркадеро ничтожная доля рынка, им нужно ее завоевывать.

Цитата Shaggy @ 16.07.14, 16:35

как ты правильно заметил в С++ интерфейсов нет, по крайней мере в языке это не зафиксировано

А C++ нынче единственный язык? Да и на момент создания COM уже был Objective-C и NextStep с его PDO, с которого этот самый COM частично слизали. И, угадай, как реализованы интерфейс и подсчет ссылок в Objective-C?

Цитата Shaggy @ 16.07.14, 16:35

а ещё это что-то используют в качестве namespace/modules, нас должно смущать наличие у нас unit'ов?

Как бы модули (и интерфейсы модулей) есть много где, тут у делфи никакой уникальности.

Цитата Shaggy @ 16.07.14, 16:35

я не по этому примеру, а вообще(он просто в качестве иллюстрации)
на момент использования ссылки переменная может уже не существовать, в отличие от объекта

И к чему это? Ссылка (грубо) ссылается на некоторое место в памяти (объект), какое ей дело до переменной? Ей важно, чтобы это место было доступно (объект существовал). В чем проблема-то?

Цитата Qraizer @ 16.07.14, 16:43

Короче, korvin, я поясняю.

Не, я понял как оно работает и почему. Мне непонятно собственно зачем оно так сделано и как с этим нормально жить. Скажем, почему нельзя было IInterface оставить совсем пустым, а для COM сделать что-то отдельное, ну там директиву какую-нибудь, их и так полно в Делфи, одной меньше, одной больше или хотя бы тот самый пресловутый IUnknown, который предоставляет нужные методы? Один хрен в компиляторе специальная магия для интерфейсов, думаю ограничить ее сверху конкретным интерфейсом было бы не сложно.

Но видимо ты прав, похоже этот вопрос

Цитата Qraizer @ 16.07.14, 16:43

можно повторять и повторять многократно

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

Qraizer — Wed, 16 Jul 2014 16:54:11 +0000

Qraizer:

Цитата D_KEY @ 16.07.14, 16:46

Они ничем не отличались бы от абстрактных классов.

Не совсем. Интерфейсы аналогичны частному виду абстрактных классов (только чистые методы + только без атрибутов класса) и частному же варианту их использования (только виртуальное наследование "интерфейсов"). Короче если, возможности абстрактных классов включают возможности интерфейсов, но первые шире вторых. Потому интерфейсов как отдельных сущностей не требуется. При этом справедливости ради следует заметить, что абстрактные классы тоже надо уметь правильно готовить, чтобы получить интерфейсы, иначе неподготовленный программер получит на выходе такую же кашу, как получил korvin с TInterfacedObject.

Добавлено 16.07.14, 16:58
jack128, получается .Value. -- это аналог ->, да? А счётчики по каким правилам будут меняться? В смысле, что их меняет?

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

D_KEY — Wed, 16 Jul 2014 16:46:31 +0000

D_KEY: Shaggy, в C++ есть множественное наследование, поэтому чистые интерфейсы, как сущность языка, не требуются. Они ничем не отличались бы от абстрактных классов. Но я так и не понял, при чем тут подсчет ссылок? Зачем его пихать в интерфейсы, да ещё и криво?

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

Qraizer — Wed, 16 Jul 2014 16:43:22 +0000

Qraizer: Короче, korvin, я поясняю. Подсчёт ссылок введён для интерфейсов и только для них. Это всего лишь средство автоматизировать COM-овские необъектные IUnknown::AddRef()/IUnknown::Release(). Необъектные потому, что COM - это объектная технология для любых, включая необъектные, ЯП, реализованная в ОС и ею же предоставляемая посредством API. Это "всего лишь средство автоматизации" не предназначалось больше ни для чего и не должно использоваться больше ни для чего. Ежели у тебя иная архитектурная конструкция классов, особенно если смешанная на интерфейсах/делегатах, будь добр сам её и пиши. Прикол же в том, что никогда не работать с объектами вообще OR никогда не юзать интерфейсы - а только так можно дружить с ними обоими, т.е. попеременно - на практике получается нечасто. Вопрос "на кой хрен было вводить такую фичу, которая решает половину проблем и параллельно создаёт столько же новых на стыке технологий" можно повторять и повторять многократно. Если б в Плюсы вносили всё, что в своё время предлагалось, он бы и 98-го года не пережил.

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

Shaggy — Wed, 16 Jul 2014 16:35:14 +0000

Shaggy:

Цитата korvin @ 16.07.14, 15:41

++? Еще раз: и? Как COM-интерфейсы связаны с ЯП-интерфейсами, которые существовали еще до COM, и в том же C++ ими назывались классы, имеющие только абстрактные методы (т.к. отдельное ключевое слово вводить не стали)?

ну вот microsoft не постеснялась "подменить понятия"(они конечно не язык изменили, а библиотеку написали, но всё-таки..), и?
и как можно подменить то, чего не существует? как ты правильно заметил в С++ интерфейсов нет, по крайней мере в языке это не зафиксировано
что-то используют в качестве интерфейсов и всё.
а ещё это что-то используют в качестве namespace/modules, нас должно смущать наличие у нас unit'ов? или скорее наоборот С++ники должны смущаться от подмены понятий?

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

Цитата korvin @ 16.07.14, 13:38

Кстати говоря, ты можешь убрать вызов SetLink и посмотреть, что будет.

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

jack128 — Wed, 16 Jul 2014 16:31:31 +0000

jack128:

Цитата korvin @ 16.07.14, 16:06

И про это и про привязку механизма подсчета ссылок к интерфейсам. Т.е. если я захочу использовать подсчет ссылок для объектов своего класса, мне придется 1) реализовать IInterface и либо изменить все места в коде, где ранее использовался класс (а это может быть невозможно, привет Sender: TObject), либо реализовать _AddRef/_Release таким образом, чтобы они не удаляли объект.

var

MyObj: TSharedPtr<TMyObject>;

begin

MyObject := TSharedPtr.Create(TMyObject.Create(Args));

Call(MyObj.Value) ; // Value - свойство для получения сырого объекта

MyObj.Value.MyMethod();

end; // счетчик ссылок обнуляется, объект уничтожается

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

Qraizer — Wed, 16 Jul 2014 16:27:22 +0000

Qraizer:

Цитата korvin @ 16.07.14, 15:11

Отчасти так и есть. Legacy-софт, legacy-DBFки, тоже еще одно порождение воспаленного мозга.

О, господи. Я тебе сочувствую. Сталкивался.

Цитата Shaggy @ 16.07.14, 15:23

намеренное коверканье названия компании-производителя, вероятно, является признаком деловитости
как и цель этого действа

Это является признаком моего к ней отношения. Это короче, чем сыпать прилагательными. И вежливее заодно. В этом и цель. Заметь, к Борланд у меня всегда были тёплые чувства и таковыми они и остались.

Цитата Shaggy @ 16.07.14, 15:23

какая фабрика? по какому интерфейсу? что за ересь?
...

Вот мы и пришли к консенсусу. Не конкретно мы с тобой, а все мы с конкретно Дельфями. Вот так вот многословно ты рассказал всё то, что до тебя рассказывали мы, разные, покороче и в разных постах. Значит мы всё правильно поняли. Вопрос "а нафик такая фича нужна, если её долго понимать, в ней легко запутаться, она конфликтует с другими предоставляемыми родными же механизмами Дельфей, если это всё легко делается гораздо проще, удобнее, безопаснее и с тем же профитом" остался без ответа, отличного от "у нас таков устав".

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

korvin — Wed, 16 Jul 2014 16:06:38 +0000

korvin:

Цитата Shaggy @ 16.07.14, 15:48

объект может узнать количество сслылок(если реализован подсчёт) и всё

При этом он ничего не знает про объектные ссылки на самого себя, т.к. сам себе реализует подсчет, а компилятор вызывает _AddRef/_Release только для интерфейсных ссылок.

Цитата Shaggy @ 16.07.14, 15:48

ты про обязательную реализацию IInterface?

Цитата Shaggy @ 16.07.14, 15:48

так и у нас также

И нет, не также. Я же говорю: в плюсах я не наследую от shared_ptr и даже не реализую его методы и уж точно мне не придется их реализовывать пустыми, чтобы он не удалил какие-то другие ссылки, я просто не буду его использовать. При этом у меня остаются и используются и классы, и интерфейсы. Захотел подсчет ссылок --- добавил shared_ptr где надо, не захотел --- не добавил. При этом иерархия моих классов/интерфейсов остается нетронутой.

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

Shaggy — Wed, 16 Jul 2014 15:48:54 +0000

Shaggy:

Цитата korvin @ 16.07.14, 15:11

тут непонятного? Ссылка на объект в тех же плюсах, хоть сырая (сырой указатель), хоть умная --- это отдельный от основного объект.

так и у нас также
объект может узнать количество сслылок(если реализован подсчёт) и всё

Цитата korvin @ 16.07.14, 15:11

Ты не наследуешься от shared_ptr или любого другого *_ptr, а строишь свою иерархию как тебе удобно, хоть с интерфейсами, хоть без. А уже потом, когда дело доходит до создания, управления временем жизни объекта и использования, ты сам выбираешь где и как тебе поступить. Явным образом.

если ты про объекты, то интерфейс может быть реализован на любом уровне иерархии
привязки к TInterfacedObject нет(это просто готовая заготовка)

или ты про обязательную реализацию IInterface?

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

korvin — Wed, 16 Jul 2014 15:41:34 +0000

korvin:

Цитата Shaggy @ 16.07.14, 15:32

фреймворк был аналогом интерфейсной ссылки, а действие в обход аналог объектной

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

Цитата Shaggy @ 16.07.14, 15:32

какой язык?

C++? Еще раз: и? Как COM-интерфейсы связаны с ЯП-интерфейсами, которые существовали еще до COM, и в том же C++ ими назывались классы, имеющие только абстрактные методы (т.к. отдельное ключевое слово вводить не стали)?

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

Shaggy — Wed, 16 Jul 2014 15:32:27 +0000

Shaggy:

Цитата korvin @ 16.07.14, 15:11

Здрасте, приехали. Вот так сюрприз. Значит зря в той же SICP рассказывается об абстракциях? Значит зря мы используем объектно-ориентированный, обобщенный и другие подходы к программированию? Да и вообще зря программируем, ведь это ничто иное как абстрагирование деталей реального мира в компьютерную модель.

ну всё, тушите свет :lol:
ты подтвердил высказывание

пишу конкретно( :) ): фреймворк был аналогом интерфейсной ссылки, а действие в обход аналог объектной

Цитата korvin @ 16.07.14, 15:11

Майкрософт? И?

Имелось в виду: какой язык?

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

korvin — Wed, 16 Jul 2014 15:24:23 +0000

korvin:

Цитата Shaggy @ 16.07.14, 14:08

для чистоты эксперимента замени writeln на OutputDebugString и смотри окно Event Log

Заменил, посмотрел. Что с указателем, что без, поведение одинаковое.

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

Shaggy — Wed, 16 Jul 2014 15:23:52 +0000

Shaggy:

Цитата MyNameIsIgor @ 16.07.14, 13:54

временные объекты живут до конца statement.

вот. этого я незнал. спасибо
в delphi это не так(я про интерфейсы естественно)
объект будет жить до конца ов

Цитата Qraizer @ 16.07.14, 13:49

Троль не может нравится по определению.

спасибо доктор

Цитата Qraizer @ 16.07.14, 13:49

Тон у меня деловой, резкий, но не оскорбительный

Цитата Qraizer @ 16.07.14, 13:49

Так что у нас разное представление определения "как взрослые люди".

очевидно

Цитата Qraizer @ 16.07.14, 13:49

От же ж. Порог не определяется количественно, он определяется прилагательными

т.е. объективно не измеряется, а следовательно ценность ответа стремится к 0

Цитата Qraizer @ 16.07.14, 13:49

Мне вот интересно, ну создала фабрика мне объект по интерфейсу на него, счётчик 0, тут бац! эксепшн. Никакого перехода 1→0 в принципе никогда не состоится. И как теперь? Но это ещё мелочи. Что говорят архитекторы самой COM не интересно почитать?

вот об этом я и говорил, пишешь о том чего не понимаешь

Цитата Qraizer @ 16.07.14, 13:49

Мне вот интересно, ну создала фабрика мне объект по интерфейсу на него, счётчик 0, тут бац! эксепшн. Никакого перехода 1→0 в принципе никогда не состоится. И как теперь?

какая фабрика? по какому интерфейсу? что за ересь?
объект создаёт конструктор. всегда!
и не важно, реализует объект какие-либо интерфейсы или нет, есть у него счётчик или нет
пока это просто объект с ручным управлением временем жизни и работать с ним можно как с обычным объектом delphi, а в конце удалить, ручками
если эксепшн в конструкторе, вызовется деструктор
если после, то может быть утечка, если исключение не обработать
если объект реализует интерфейсы, у него есть служебные методы
если собирается вести подсчёт ссылок у него есть поле под счётчик =0(после того, как отработает конструктор), а служебные методы соответсвенно изменяют этот счётчик в ту или иную сторону
можно подёргать эти методы ручками(они в public), ни к какому автоматизму это не приведёт
и объекту насрать, есть переход 1->0 или нет
(это нормальное поведение, так и задумано!)

автоматизм начинается, когда мы запрашиваем у объекта интерфейс
появляется интерфейстная ссылка, а следовательно компилятор автоматически вызывает _addref, который в свою очередь увеличивает счётчик(но может делать что угодно, что напишете то и будет)
после этого про объектные ссылки нужно забыть и работать только через интерфейс(ниже дополнено)
т.е. по сути весь автоматизм заключается только в этом:
присваивание, передача параметром(при выходе из подпрограммы _release) - вызов _addref
присваивание nil, выход за ов - _release
т.е. не компилятор вызывает деструктор и следит за счётчиком, а в этих методах это реализовано(повторюсь, стандартная реализация, вы можете написать любую другую)

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

Цитата Qraizer @ 16.07.14, 13:49

Но это ещё мелочи. Что говорят архитекторы самой COM не интересно почитать?

читал
а ты? и понял? или нужны пояснения?

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

korvin — Wed, 16 Jul 2014 15:11:26 +0000

korvin:

Цитата D_KEY @ 16.07.14, 13:48

да вроде ничего криминального.

Ничего, только (внешне) это напоминает как раз

auto v = 1;

auto r = &v;

Цитата Shaggy @ 16.07.14, 14:08

???

Что тут непонятного? Ссылка на объект в тех же плюсах, хоть сырая (сырой указатель), хоть умная --- это отдельный от основного объект. Ты не наследуешься от shared_ptr или любого другого *_ptr, а строишь свою иерархию как тебе удобно, хоть с интерфейсами, хоть без. А уже потом, когда дело доходит до создания, управления временем жизни объекта и использования, ты сам выбираешь где и как тебе поступить. Явным образом.

Цитата Shaggy @ 16.07.14, 14:08

что может нарушить

Да, таких фреймворков стоит избегать.

Цитата Shaggy @ 16.07.14, 14:08

слишком конкретное мышление - болезнь программистов

Цитата Shaggy @ 16.07.14, 14:08

да, конкуренция. не используй, победи в конкурентной борьбе

Так практически никто и не использует, кроме ситуаций, указанных чуть ниже.

Цитата Shaggy @ 16.07.14, 14:08

такое впечаетление, что тебя заставляют писать на delphi

Отчасти так и есть. Legacy-софт, legacy-DBFки, тоже еще одно порождение воспаленного мозга.

Цитата Shaggy @ 16.07.14, 14:08

пример был взят с СОМ, чъё он порождение?

Майкрософт? И?

Цитата Shaggy @ 16.07.14, 14:08

ну и в качестве бонуса - хоть какой-то, но стандарт

Стандарт чего и где? Как это все связано с ЯП?

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

Shaggy — Wed, 16 Jul 2014 14:08:49 +0000

Shaggy:

Цитата korvin @ 16.07.14, 13:18

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

???

Цитата korvin @ 16.07.14, 13:18

Я бы еще понял, если бы ты привел пример, когда ручной доступ к БД параллельно с фреймворком, скажем, нарушает целостность данных в БД.

достаточно того, что может нарушить

Цитата korvin @ 16.07.14, 13:18

Я и не использую фреймворки.

слишком конкретное мышление - болезнь программистов и юристов да :)
это была аналогия

Цитата korvin @ 16.07.14, 13:18

Да и самому монастырю следовало бы понять, что он таки не один на Земле и далеко не ее пуп. Конкуренция, да.

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

Цитата korvin @ 16.07.14, 13:18

Большинство языков не подменяют чужие понятия своими.

пример был взят с СОМ, чъё он порождение? ну и в качестве бонуса - хоть какой-то, но стандарт

Цитата korvin @ 16.07.14, 13:38

Как будто со слабыми ссылками будет по-другому...

код будет чище, без @ и ^
а так да

Цитата korvin @ 16.07.14, 13:38

Кстати говоря, ты можешь убрать вызов SetLink и посмотреть, что будет.

Цитата korvin @ 16.07.14, 13:38

Т.е. указатель тут как бы совсем не причем

для чистоты эксперимента замени writeln на OutputDebugString и смотри окно Event Log

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

Qraizer — Wed, 16 Jul 2014 13:58:02 +0000

Qraizer:

Цитата Shaggy @ 16.07.14, 13:32

а с чего вдруг он умирает? за ов он ещё не вышел...

Он временный. Безымянный. Время жизни таковых простирается (грубо говоря) до ближайшей ;.

Цитата Shaggy @ 16.07.14, 13:32

зачем нужна ещё одна прокладка(make_shared)? конструктора shared_ptr недостаточно?

Достаточно. Просто так удобнее.

Добавлено 16.07.14, 13:58
А, ну вот MyNameIsIgor решил описать не грубо говоря.

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

MyNameIsIgor — Wed, 16 Jul 2014 13:54:48 +0000

MyNameIsIgor:

Цитата Shaggy @ 16.07.14, 13:32

ээ... а с чего вдруг он умирает? за ов он ещё не вышел...

"ов" - это область видимости? Она тут ни при чём (точнее, при чём, но распространяется на объект x), временные объекты живут до конца statement.
Напомню, код мы обсуждаем вот такой

auto x = make_shared<int>(42);

Для пример, есть у нас функция, возвращающая экземпляр некоего типа T

T foo() { return T(); }

Если вызвать её вот так

foo();

то возвращённый объект сразу умрёт. Если так

T t = foo();

то возвращённый объект будет использован при создании объекта t, а потом так же умрёт.

Цитата Shaggy @ 16.07.14, 13:32

и ещё(просто интересно), зачем нужна ещё одна прокладка(make_shared)? конструктора shared_ptr недостаточно?

Во-первых, это некоторый сахар - не надо два раза писать тип

shared_ptr<MyType> p(new MyType(arg1, arg2, arg3));

auto p = make_shared<MyType>(arg1, arg2, arg3);

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

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

Qraizer — Wed, 16 Jul 2014 13:49:50 +0000

Qraizer:

Цитата Shaggy @ 16.07.14, 11:58

Qraizer, тебе я вижу, не понравилось? так может оставишь этот снисходительный, менторский тон и поговорим нормально, как взрослые люди?

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

Цитата Shaggy @ 16.07.14, 11:58

Цитата Qraizer @ 16.07.14, 03:23

На предмет порога вхождения в Дельфи ответ будет?

а какого ответа ты ждёшь? в чём этот порог измеряется? %, попугаи?

От же ж. Порог не определяется количественно, он определяется прилагательными.

Цитата Shaggy @ 16.07.14, 11:58

Цитата Qraizer @ 16.07.14, 03:23

У korvin-а пока получается лихо пороги переступать везде, кроме Дельфей

ты считаешь это аргументом?

Я считаю это пояснением к вопросу о пороге. Аргументом это можно рассматривать, если относиться к нему как факту. Но один факт ещё не статистика. Собственно за неимением оной вопрос о пороге и был задан, иначе было бы утверждение, а не вопрос. А вот дельфисты утверждают, а не спрашивают о, высокий уровень порога вхождения в Плюсы, и не только я вижу тут противоречие.
Shaggy, мне в целом коллинеарно, что там хотел написать korvin, что вместо этого написал, и где в результате словил грабли. Поднятый мною вопрос поначалу касался только счётчика ссылок с бредовым начальным значением, затем бредового факта отсутствия владельца для этого счётчика, затем бреда о нормальности подхода к ручному допиливанию функционала, для избавления от которого этот функционал вообще-то и вводился, и только наконец -- воспринятия горы проблем из-за всего этого за нормальное проектное решение уровня архитектуры языка.
Мне вот интересно, ну создала фабрика мне объект по интерфейсу на него, счётчик 0, тут бац! эксепшн. Никакого перехода 1→0 в принципе никогда не состоится. И как теперь? Но это ещё мелочи. Что говорят архитекторы самой COM не интересно почитать?

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

D_KEY — Wed, 16 Jul 2014 13:48:24 +0000

D_KEY: korvin, да вроде ничего криминального.
Напоминает

auto v = 1;

auto r = new int(v);

Добавлено 16.07.14, 13:49
Это я про limbo.

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

korvin — Wed, 16 Jul 2014 13:38:18 +0000

korvin:

Цитата Shaggy @ 16.07.14, 13:32

т.е. корректность работы зависит от того где вызван SetLink, в или за Main

Как будто со слабыми ссылками будет по-другому...

Добавлено 16.07.14, 13:42

Цитата Shaggy @ 16.07.14, 13:32

т.е. корректность работы зависит от того где вызван SetLink, в или за Main

Кстати говоря, ты можешь убрать вызов SetLink и посмотреть, что будет.

Добавлено 16.07.14, 13:45
И еще можешь сделать так:

function Main: ICyclic;

begin

Result := TCyclic.Create('Foo');

Result.SetLink(@Result);

Result.PrintLn;

end;

procedure RealMain;

begin

Main;

end;

begin

RealMain;

ReadLn;

end.

Т.е. указатель тут как бы совсем не причем.

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

Shaggy — Wed, 16 Jul 2014 13:32:14 +0000

Shaggy:

Цитата korvin @ 16.07.14, 12:46

Указатели совсем вышли из моды? =)

шикарное решение :lol:
а если переписать так?

function Main:ICyclic;

begin

Result := TCyclic.Create('Foo');

Result.SetLink(@Result); // оопс!

Result.GetLink^.PrintLn;

end;

т.е. корректность работы зависит от того где вызван SetLink, в или за Main

Цитата MyNameIsIgor @ 16.07.14, 13:13

...счётчик равен 2, но потом временный объект, созданный функцией make_shared, умирает и тем самым уменьшает счётчик на 1, и остаётся только объект x со счётчиком 1.

ээ... а с чего вдруг он умирает? за ов он ещё не вышел...

и ещё(просто интересно), зачем нужна ещё одна прокладка(make_shared)? конструктора shared_ptr недостаточно?

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

korvin — Wed, 16 Jul 2014 13:18:12 +0000

korvin:

Цитата Shaggy @ 16.07.14, 12:57

тогда не понял. т.е. не может существовать двух ссылок(сырая и shared), указывающих на один объект?

Цитата Shaggy @ 16.07.14, 12:57

разжовываю: если ты используешь фреймворк, зачем лезть в обход?

Фреймворки бывают разные и зачастую недостаточно гибкие. И тебе не кажется, что вопрос "зачем это делать?" --- это не ответ на вопрос "почему так делать --- дурной тон?" и уж тем более никак не катит на "разжевывание". Я бы еще понял, если бы ты привел пример, когда ручной доступ к БД параллельно с фреймворком, скажем, нарушает целостность данных в БД.

Цитата Shaggy @ 16.07.14, 12:57

а если фреймворк - моветон, зачем ты его используешь?

Я и не использую фреймворки.

Цитата Shaggy @ 16.07.14, 12:57

вот про это я и говорю: со своим уставом в чужой монастырь...

С этим никто не спорит, но из-за такого устава монастыря ходить в него совсем не хочется, а приходится иногда.

Да и самому монастырю следовало бы понять, что он таки не один на Земле и далеко не ее пуп. Конкуренция, да.

Цитата Shaggy @ 16.07.14, 12:57

если ты учишь phyton, ты будешь возмущаться, что там не так как в С++?

Большинство языков не подменяют чужие понятия своими. Если им хочется что-то сделать "не как у всех", они придумывают новые понятия, дабы не создавать путаницу.

Например, делфисты любят рассказывать, какое Делфи "компонентно-ориентированное", вот и использовали бы вместо слова "interface" слово "component", хотя оно не совсем точно отражало бы суть, но зато без путаницы.

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

MyNameIsIgor — Wed, 16 Jul 2014 13:13:44 +0000

MyNameIsIgor:

Цитата Shaggy @ 16.07.14, 11:58

мне сказали, что конструкция
make_shared(42);
выдаёт объект со счётчиком=1
далее следует присвоение, и следовательно...

Цитата Shaggy @ 16.07.14, 11:58

а без последней фразы ты не мог, это да... молодец чё

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

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

korvin — Wed, 16 Jul 2014 13:04:03 +0000

korvin:

Давайте сделаем небольшое лирическое отступление

(чтоб делфисты не чувствовали себя уникальными =)). Недавно наткнулся на еще один пример не совсем очевидного поведения в совсем другом языке.

В Limbo структуры являются типами значений (как в C, Go и т.п.), например:

Int: adt

{

val: int;

};

Также существует ключевое слово ref, для создания ссылочных структур (ref можно использовать только с adt-типами), например:

IntRef: type ref Int;

x: IntRef;

или просто

x: ref Int;

Однако, в следующем коде

v := Int(1);

r := ref v;

ref v не вернет ссылку на v, как операция взятия адреса в других языках, она создаст новую ссылку на Int и скопирует туда значение v.

Пруф:

implement Command;

include "sys.m";

sys: Sys;

include "draw.m";

Command: module

{

init: fn(nil: ref Draw->Context, nil: list of string);

};

init(nil: ref Draw->Context, nil: list of string)

{

sys = load Sys Sys->PATH;

sys->print("ref = %d\n", <-spawnThread());

}

Int: adt

{

val: int;

};

spawnThread(): chan of int

{

c := chan of int;

v := Int(1);

r := ref v;

sys->print("ref = %d, val = %d\n", r.val, v.val);

spawn thread(c, r);

sys->sleep(1000);

sys->print("ref = %d, val = %d\n", r.val, v.val);

r.val = 3;

return c;

}

thread(out: chan of int, r: ref Int)

{

sys->sleep(500);

r.val = 2;

sys->sleep(1000);

out <-= r.val;

}

ref = 1, val = 1

ref = 2, val = 1

ref = 3

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

Shaggy — Wed, 16 Jul 2014 12:57:30 +0000

Shaggy:

Цитата korvin @ 16.07.14, 12:33

На один и тот же объект.

тогда не понял. т.е. не может существовать двух ссылок(сырая и shared), указывающих на один объект?

Цитата korvin @ 16.07.14, 12:33

Скажи, почему нет интерфейсов для VCL-компонентов

потому-что интерфейсы появились позже VCL
повсеместного введения плюшек последнего стандарта C++ я тоже не наблюдаю

Цитата korvin @ 16.07.14, 12:33

Кем считается? Сейчас вроде модно наоборот, фреймворки считать моветоном.

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

Цитата korvin @ 16.07.14, 12:33

Да, потому что тут везде всё в порядке, кроме Делфи.

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

Цитата korvin @ 16.07.14, 12:33

ARC --- Automatic Reference Counting

значит неправильно понипал

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

D_KEY — Wed, 16 Jul 2014 12:48:34 +0000

D_KEY:

Цитата Shaggy @ 16.07.14, 11:58

напишу прямо: не используй разные ссылки на один объект, не надо...

Звучит как: "не используйте ООП, не надо"...

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

korvin — Wed, 16 Jul 2014 12:46:26 +0000

korvin:

Цитата Shaggy @ 16.07.14, 11:58

weak ref's

Указатели совсем вышли из моды? =)

program Test;

{$APPTYPE CONSOLE}

uses

SysUtils,

Classes;

type

PICyclic = ^ICyclic;

ICyclic = interface

procedure PrintLn;

procedure SetLink(L: PICyclic);

function GetLink: PICyclic;

end;

TCyclic = class(TInterfacedObject, ICyclic)

private

FName: string;

FLink: PICyclic;

public

constructor Create(Name: string);

destructor Destroy; override;

function _AddRef: Integer; stdcall;

function _Release: Integer; stdcall;

procedure PrintLn; virtual;

procedure SetLink(L: PICyclic); virtual;

function GetLink: PICyclic; virtual;

end;

constructor TCyclic.Create(Name: string);

begin

FName := Name;

WriteLn('created');

end;

destructor TCyclic.Destroy;

begin

WriteLn('destroyed');

inherited;

end;

function TCyclic._AddRef: Integer;

begin

Result := inherited _AddRef;

WriteLn('referenced ' + IntToStr(Result));

end;

function TCyclic._Release: Integer;

begin

Result := inherited _Release;

WriteLn('released ' + IntToStr(Result));

end;

procedure TCyclic.PrintLn;

begin

WriteLn(FName);

end;

procedure TCyclic.SetLink(L: PICyclic);

begin

FLink := L;

end;

function TCyclic.GetLink: PICyclic;

begin

Result := FLink;

end;

procedure Main;

var c: ICyclic;

begin

c := TCyclic.Create('Foo');

c.SetLink(@c);

c.GetLink^.PrintLn;

end;

begin

Main;

ReadLn;

end.

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

D_KEY — Wed, 16 Jul 2014 12:40:30 +0000

D_KEY:

Цитата Shaggy @ 16.07.14, 11:58

Цитата korvin @ 16.07.14, 03:29

Угу, только shared_ptr -- 1) это другой объект, а не наш, 2) использование shared_ptr не ограничивает меня в способах построения иерархии своих классов.

1. так и у меня ссылки разные
2. интерфейсы меня тоже не ограничивают

У тебя один и тот же "вид" ссылок. По крайней мере явно.
Как же тебе не мешают интерфейсы, если ты при их использовании должен непонятно почему думать о подсчете ссылок, хотя интерфейсы не имеют никакого отношения к управлению памятью. По крайней мере не должны. Связь-то какая между понятием интерфейса в ООП и механизмами управления памятью? Зачем так в Delphi сделали?

Цитата

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

Т.е. интерфейсы в Delphi используют не как интерфейсы, а как механизм подсчета ссылок? Тогда их следовало назвать иначе.

Цитата

помнишь споры вокруг void и pointer? ничего общего не находишь?

Эм. Пока нет. Раскрой тему.

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

korvin — Wed, 16 Jul 2014 12:33:52 +0000

korvin:

Цитата Shaggy @ 16.07.14, 11:58

1. так и у меня ссылки разные

На один и тот же объект. google: object identity.

Цитата Shaggy @ 16.07.14, 11:58

интерфейсы меня тоже не ограничивают

Ко многому можно привыкнуть, да. Скажи, почему нет интерфейсов для VCL-компонентов и как мне создать, скажем, свою Label, не наследуясь ни от TLabel, ни от любого из его предков?

Цитата Shaggy @ 16.07.14, 11:58

почему-то лезть в базу, например, в обход используемого фреймворка
считается моветоном

Кем считается? Сейчас вроде модно наоборот, фреймворки считать моветоном.

Цитата Shaggy @ 16.07.14, 11:58

а тут всё в порядке?

Да, потому что тут везде всё в порядке, кроме Делфи.

Цитата Shaggy @ 16.07.14, 11:58

насколько знаю, планируется ввести ARC(если я правильно понимаю, что это такое)

ARC --- Automatic Reference Counting. И он никак не решает проблему циклических ссылок. Он ее скорее как раз создает. И у вас же уже есть ARC в интерфейсах, зачем вводить еще один какой-то?

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

Shaggy — Wed, 16 Jul 2014 11:58:52 +0000

Shaggy: тут следовало бы написать: гы, сколько пуканов порвалось! :crazy:

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

Qraizer, тебе я вижу, не понравилось? так может оставишь этот снисходительный, менторский тон и поговорим нормально, как взрослые люди?
ты вроде пишешь правильные и умные вещи... про С++
и у тебя почти получается писать про delphi,
но временами ты выдаёшь такой... ну кроме как бредом назвать нельзя...

Цитата MyNameIsIgor @ 16.07.14, 01:39

По его объяснениям (и по факту) счётчик здесь равен 1. Как и в Objective-C. Только в дельфях всё через...

мне сказали, что конструкция
make_shared(42);
выдаёт объект со счётчиком=1
далее следует присвоение, и следовательно...

в моих словах отсутствует логика?

а без последней фразы ты не мог, это да... молодец чё

Цитата Qraizer @ 16.07.14, 03:23

На предмет порога вхождения в Дельфи ответ будет?

а какого ответа ты ждёшь? в чём этот порог измеряется? %, попугаи?

Цитата Qraizer @ 16.07.14, 03:23

У korvin-а пока получается лихо пороги переступать везде, кроме Дельфей

ты считаешь это аргументом?
у меня тоже с этим никаких проблем, и использование delphi мне никак не мешало

Цитата korvin @ 16.07.14, 03:29

1. так и у меня ссылки разные
2. интерфейсы меня тоже не ограничивают

Цитата korvin @ 16.07.14, 03:29

Так это у вас надо спрашивать, у вас же разница есть.

это было сравнение с++ и delphi подхода

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

почему-то лезть в базу, например, в обход используемого фреймворка
считается моветоном
а тут всё в порядке?

Цитата korvin @ 16.07.14, 03:29

Просто, как обычно, у Делфи свой путь. Куда-то далеко.

это ты куда-то далеко идёшь

Цитата D_KEY @ 16.07.14, 10:44

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

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

помнишь споры вокруг void и pointer? ничего общего не находишь?

Добавлено 16.07.14, 12:02

Цитата korvin @ 16.07.14, 03:29

Я так понимаю, решение проблемы циклических ссылок тоже отдан на откуп программисту:

да

Цитата D_KEY @ 16.07.14, 10:44

Кстати да, есть ли безопасный способ разруливать циклияеские ссылки?

насколько знаю, планируется ввести ARC(если я правильно понимаю, что это такое)
и weak ref's

может в ХЕ6 уже и есть, я не в курсе

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

D_KEY — Wed, 16 Jul 2014 10:44:34 +0000

D_KEY: Кстати да, есть ли безопасный способ разруливать циклияеские ссылки?

Добавлено 16.07.14, 10:48

Цитата Shaggy @ 16.07.14, 00:36

Цитата D_KEY @ 14.07.14, 20:21

что ссылка с подсчетом ссылок и без зависит от места в иерархии.

ничего не понял. что за иерархия?

Работаешь через ссылку на интерфейс - получаешь одно поведение, работаешь через ссылку на объект - другое. И совершенно непонятно, зачем мне это нужно... Я так понимаю, что везде, кроме Delphi, подсчет ссылок ортогонален интерфейсам, наследованию и пр. механизмам ООП.

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

korvin — Wed, 16 Jul 2014 03:29:47 +0000

korvin:

Цитата Shaggy @ 16.07.14, 00:36

(видимо сценарий действительно редкий и стандартной заготовки нет. пришлось изобретать TNoRefObject)

Потому и редкий, что "всё через..."

Цитата Shaggy @ 16.07.14, 00:36

из shared_ptr можно получить сырой указатель?

Угу, только shared_ptr -- 1) это другой объект, а не наш, 2) использование shared_ptr не ограничивает меня в способах построения иерархии своих классов.

Цитата Shaggy @ 16.07.14, 00:36

ссылка на объект(весь интерфейс объекта) vs часть этого интерфейса. и какая разница?

Так это у вас надо спрашивать, у вас же разница есть.

Цитата Shaggy @ 16.07.14, 00:36

уничтожается при переходе 1->0

Об этом и речь.

Цитата Shaggy @ 16.07.14, 00:36

просто ты захотел выстрелить себе в ногу
у тебя получилось...

Просто, как обычно, у Делфи свой путь. Куда-то далеко.

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

Цитата Qraizer @ 16.07.14, 03:23

растущее из Абракадеро

Так это наверное еще со времен Борланда тянется.

Добавлено 16.07.14, 03:38
BTW, почему было изначально не сделать управление жизнью объектов только через ARC, не было бы путаницы и это снизило бы порог вхождения. У меня два живых примера "перед глазами", оба пишут на Делфи, но оба понятия не имеют про классы/объекты/динамическую память/время жизни. Потому и пишут фактически процедурный код. Слишком сложно в объекты для формошлеперов.

Добавлено 16.07.14, 03:58

Цитата Shaggy @ 16.07.14, 00:36

тут два варианта

Я так понимаю, решение проблемы циклических ссылок тоже отдан на откуп программисту:

program Test;

{$APPTYPE CONSOLE}

{$R *.res}

uses

SysUtils,

Classes;

type

ICyclic = interface

procedure SetLink(L: ICyclic);

end;

TCyclic = class(TInterfacedObject, ICyclic)

private

FLink: ICyclic;

public

constructor Create;

destructor Destroy; override;

function _AddRef: Integer; stdcall;

function _Release: Integer; stdcall;

procedure SetLink(L: ICyclic); virtual;

end;

constructor TCyclic.Create;

begin

inherited;

WriteLn('created');

end;

destructor TCyclic.Destroy;

begin

WriteLn('destroyed');

inherited;

end;

function TCyclic._AddRef: Integer;

begin

Result := inherited _AddRef;

WriteLn('referenced ' + IntToStr(Result));

end;

function TCyclic._Release: Integer;

begin

Result := inherited _Release;

WriteLn('released ' + IntToStr(Result));

end;

procedure TCyclic.SetLink(L: ICyclic);

begin

FLink := L;

end;

procedure Main;

var c: ICyclic;

begin

c := TCyclic.Create;

c.SetLink(c);

end;

begin

Main;

ReadLn;

end.

created

referenced 1

referenced 2

referenced 3

released 2

released 1

Хотя во всех (или почти всех) языках, где используется ARC, этот вопрос так или иначе решен.

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

Qraizer — Wed, 16 Jul 2014 03:23:34 +0000

Qraizer:

Цитата Shaggy @ 16.07.14, 00:36

выдуманные проблемы с++шников, которые лезут со своим уставом в чужой монастырь

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

Цитата MyNameIsIgor @ 16.07.14, 01:39

о его объяснениям (и по факту) счётчик здесь равен 1. Как и в Objective-C. Только в дельфях всё через...

MyNameIsIgor, если б он читал, что ему пишут, а не искал знакомые буквы, то вот это вот

Цитата Qraizer @ 15.07.14, 02:36

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

я б не спрашивал.
И -- да, в Дельфях если не вообще всё, то уж точно всё растущее из Абракадеро, через. Ибо и вот это вот

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

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

сказанное в адрес Objective-C, не насторожило. Shaggy, вас Абракадеро очередной раз кинуло, поленившись сделать правильно и сделав, как им проще, вам втюхать как догму, а вы и рады уши развесить. Кроме Дельфей, нигде больше ссылки так не считают. Всё, что есть Дельфях, можно найти ещё где-нибудь. Любые качества, фичи, итд. Но вот ссылки на интерфейсы есть только тут. Ну ещё в COM, но это и не язык.

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

MyNameIsIgor — Wed, 16 Jul 2014 01:39:32 +0000

MyNameIsIgor:

Цитата Shaggy @ 16.07.14, 00:36

тут счётчик равен чему?
судя по объяснениям Qraizer - 2

По его объяснениям (и по факту) счётчик здесь равен 1. Как и в Objective-C. Только в дельфях всё через...

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

Shaggy — Wed, 16 Jul 2014 00:36:55 +0000

Shaggy:

Цитата D_KEY @ 14.07.14, 20:21

что ссылка с подсчетом ссылок и без зависит от места в иерархии.

ничего не понял. что за иерархия?
если ту имеешь в виду то, что нужно наследоваться от TInterfacedObject
то это не так

Цитата Qraizer @ 15.07.14, 02:36

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

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

Цитата Qraizer @ 15.07.14, 02:36

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

raw mind?
выдуманные проблемы с++шников, которые лезут со своим уставом в чужой монастырь

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

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

не переопределять, а писать с нуля, этих методов нет в TObject

если мы хотим автоматики
стандартный шаблон:
1. создаём объект
2. запрашиваем интерфейс(любой из тех, что реализованы)
3. и далее работаем с объектом только посредством интерфейсов
4. если нам надо передать интерфейс в функцию/метод без увеличения счётчика, используем const(пример я уже приводил)

var

O:TObj;

I:IMyIntf;

begin

O:=TObj.Create;

I:=O as IMyIntf;

I.Work;

doSomething(I);

end;

на практике, объектная ссылка просто не нужна

var

I:IMyIntf;

begin

I:=TObj.Create;

I.Work;

doSomething(I);

end;

иногда возникает ситуация, когда в программе мы работаем только с объектами, а в какую-то внешнюю функцию
надо передать интерфейс(т.е. писали её не мы и изменить не можем)
тут два варианта
а) либо в соответствии с п.3 переписываем всё на интерфейсах
б) либо реализуем интерфейс только там, где нужно, без подсчёта ссылок
(видимо сценарий действительно редкий и стандартной заготовки нет. пришлось изобретать TNoRefObject)
(тут использование const на счётчик не повлияет т.к. его нет :) но уберёт ненужные вызовы служебных методов)

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

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

насколько знаю С++ - тоже
из shared_ptr можно получить сырой указатель?

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

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

ссылка на объект(весь интерфейс объекта) vs часть этого интерфейса. и какая разница?

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

Либо считайте ссылки объекта, либо не уничтожайте объект при значении счетчика == 0.

считаем, не уничтожается
уничтожается при переходе 1->0

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

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

хинтов по поводу?
все контракты выполняются
никаких неоднозначностей нет
все переменные инициализированы

просто ты захотел выстрелить себе в ногу
у тебя получилось...

кстати

Цитата D_KEY @ 13.07.14, 12:04

auto x = make_shared(42);

тут счётчик равен чему?
судя по объяснениям Qraizer - 2
?

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

Qraizer — Tue, 15 Jul 2014 16:54:01 +0000

Qraizer: О, блин. Долго ждал :D ?

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

Славян — Tue, 15 Jul 2014 16:50:18 +0000

Славян: :blush: С троичным юбилеем странички! 3⁵ = 243. :blush:

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

Qraizer — Tue, 15 Jul 2014 16:39:23 +0000

Qraizer: Я не думаю, что от него хоть какой-то прок будет, пусть даже маленький. Однако библиотеки есть, хоть и маловостребованы. Значит, кому-то нужно, а я просто не в курсе.

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

D_KEY — Tue, 15 Jul 2014 16:29:58 +0000

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

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

MyNameIsIgor — Tue, 15 Jul 2014 15:45:19 +0000

MyNameIsIgor:

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

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

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

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

Qraizer — Tue, 15 Jul 2014 15:26:43 +0000

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

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

MyNameIsIgor — Tue, 15 Jul 2014 11:54:36 +0000

MyNameIsIgor:

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

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

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

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

Qraizer — Tue, 15 Jul 2014 11:50:24 +0000

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

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

MyNameIsIgor — Tue, 15 Jul 2014 11:24:59 +0000

MyNameIsIgor:

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

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

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

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

Qraizer — Tue, 15 Jul 2014 11:07:27 +0000

Qraizer:

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

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

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

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

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

D_KEY — Tue, 15 Jul 2014 09:55:07 +0000

D_KEY:

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

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

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

Rust?

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

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

korvin — Tue, 15 Jul 2014 09:15:49 +0000

korvin:

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

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

Rust?

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

Мяут-Настоящий — Tue, 15 Jul 2014 08:06:33 +0000

Мяут-Настоящий: 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 }

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

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

D_KEY — Tue, 15 Jul 2014 07:20:12 +0000

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

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

Мяут-Настоящий — Tue, 15 Jul 2014 04:42:18 +0000

Мяут-Настоящий:

Цитата 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# где таких граблей нет.

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

korvin — Tue, 15 Jul 2014 03:16:58 +0000

korvin:

Цитата 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

и?

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

Qraizer — Tue, 15 Jul 2014 02:36:09 +0000

Qraizer:

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

с чего вдруг?

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

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

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

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

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

D_KEY — Mon, 14 Jul 2014 20:21:31 +0000

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

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

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

Shaggy — Mon, 14 Jul 2014 19:36:36 +0000

Shaggy:

Цитата D_KEY @ 14.07.14, 18:15

А shared_ptr лучше явным поведением, отсутствием привязки к иерархии и каким-то другим языковым конструкциям.

Цитата korvin @ 14.07.14, 18:24

Тем, что shared_ptr не навязывает моему классу и моему интерфейсу какие-либо методы и поведение и я (в моем случае) могу даже не вспоминать о его существовании. А если он мне понадобится --- не заботиться о каких-то служебных методах для его корректной работы.

он лучше только тем, что "прозрачный"

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

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

А должен

с чего вдруг?

Цитата korvin @ 14.07.14, 18:24

Я хотел простые интерфейсы, как везде.

первый вариант

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

Цитата korvin @ 14.07.14, 18:24

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

procedure Build(const W: IWriter; S: string);

addref и release дёргаться не будут

Цитата korvin @ 14.07.14, 18:24

О чем и речь, вместо наполнения пустого ящика нужными вещами, берем ящик с хламом и предварительно его вычищаем. Delphi-way, че.

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

Цитата korvin @ 14.07.14, 18:24

И на кой черт нам считать ссылки на интерфейсы, если время жизни --- это характеристика объекта, лежащего за этими интерфейсами?

да объекта, и?

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

Qraizer — Mon, 14 Jul 2014 19:07:22 +0000

Qraizer: Не ну Дельфи-то понять можно, korvin. Унаследовав COM к себе и приняв его вынужденные ограничения, Дельфи с COM-интерфейсами иначе никак и не поступить. Хочешь считать не интерфейсы, а объекты, перекрывай счётчики и реализуй сообразно. Другое дело, что COM-интерфейсы - это не те интерфейсы, которые первыми приходят на ум, когда слышишь "интерфейс". И почему, кроме COM, никаких других Дельфи не даёт, вот это непонятно.

Добавлено 14.07.14, 19:07
Хотя если рассуждать здраво, наплодить ещё одну сущность в довесок к имеющимся, так Дельфи ещё тяжелее станет, а профям и так сойдёт.

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

D_KEY — Mon, 14 Jul 2014 18:41:43 +0000

D_KEY: Кстати, в C++ обычно передают shared_ptr по ссылке, чтоб избежать лишней работы со счетчиками.

void foo(const shared_ptr<IFoo> &ptr)

В Delphi, как я понимаю, так не сделать?

Добавлено 14.07.14, 18:51
korvin, единственное что, у нас иногда приходится возиться с shared_from_this. В Delphi, видимо, не придётся ничего дополнительного делать.

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

korvin — Mon, 14 Jul 2014 18:24:17 +0000

korvin:

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

выбор варианта зависит от того, что же ты на самом деле хотел

Я хотел простые интерфейсы, как везде.

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

TNoRefObject = class(TObject, IInterface)

...

Цитата Shaggy @ 14.07.14, 17:41

в чём принципиальное отличие от shared_ptr?

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

считаем ссылки, сколько раз запросили интерфейс(любой) столько и ссылок имеется understand?

И на кой черт нам считать ссылки на интерфейсы, если время жизни --- это характеристика объекта, лежащего за этими интерфейсами?

Добавлено 14.07.14, 18:32
Кроме того, если я уверен, что в процедуре, которая требует интерфейс (такая вот библиотечная процедура, множественного наследования-то нет, вот, чтобы не ограничивать пользователя на реализацию объекта, она и просит интерфейс), не сохранится ссылок, то зачем мне вообще в данном случае сталкиваться со счетчиком ссылок (но в других случаях я хочу, чтоб ссылки считались)?

Foo(x); // -- сюда я хочу передать "сырую ссылку"

Bar(x); // -- а сюда "инкрементированую"

// потому что здесь я "потеряю" ссылку на x

Как быть?

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

Qraizer — Mon, 14 Jul 2014 18:20:28 +0000

Qraizer:

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

то, что ссылается, им не владеет. т.е. не контролирует время жизни

Воот. А должен. Никто не владеет, некому и считать ссылки. Отсюда в частности и обсуждаемые проблемы. Сырыми поинтерами в Сях/Плюсах тоже никто не владеет, так что знаем, каково это.

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

D_KEY — Mon, 14 Jul 2014 18:15:21 +0000

D_KEY: А что мы на последних страницах обсуждаем? И вполне себе конструктивно было...

А shared_ptr лучше явным поведением, отсутствием привязки к иерархии и каким-то другим языковым конструкциям. Это вообще обычный библиотечный класс.

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

Shaggy — Mon, 14 Jul 2014 17:41:56 +0000

Shaggy: конструктивненько...

в чём принципиальное отличие от shared_ptr?

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

D_KEY — Mon, 14 Jul 2014 17:33:40 +0000

D_KEY: Shaggy, ну идиотизм же. Зачем ты это защищаешь?

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

Shaggy — Mon, 14 Jul 2014 16:45:11 +0000

Shaggy: :lol:
#3566

1. W:IWriter; а W.Free; убрать
2. procedure Build(W:TWriter; S:string);
3.

TNoRefObject = class(TObject, IInterface)

protected

function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;

function _AddRef: Integer; stdcall;

function _Release: Integer; stdcall;

end;

function TNoRefObject.QueryInterface(const IID: TGUID; out Obj): HResult;

begin

if GetInterface(IID, Obj) then

Result := 0

else

Result := E_NOINTERFACE;

end;

function TNoRefObject._AddRef: Integer;

begin

Result := MAXINT;

end;

function TNoRefObject._Release: Integer;

begin

Result := MAXINT;

end;

и
TWriter = class(TNoRefObject, IWriter)

выбор варианта зависит от того, что же ты на самом деле хотел

Добавлено 14.07.14, 17:04

Цитата Qraizer @ 14.07.14, 16:03

то, что ссылается, им не владеет. т.е. не контролирует время жизни

Цитата Qraizer @ 14.07.14, 16:03

В Дельфи что, в натуре считается нормальным, когда интерфейсы живут сами по себе безо всяких их реализующих объектов

на основании чего был сделан этот вывод? это физически неозможно

Цитата Qraizer @ 14.07.14, 16:03

Не запутались там в своих ссылках ещё, нет?

а вы в своих?

Цитата Qraizer @ 14.07.14, 16:03

Снова вопрошаю: на кой хрен считать интерфейсы?

считаем ссылки, сколько раз запросили интерфейс(любой) столько и ссылок имеется understand?

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

D_KEY — Mon, 14 Jul 2014 16:18:20 +0000

D_KEY:

Цитата korvin @ 14.07.14, 14:32

Цитата D_KEY @ 14.07.14, 13:47

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

Знаешь как они докатились до жопы такой? Вот смотри:

procedure Foo(x: IInterface);

...

Foo(TInterfacedObject.Create);

Объект создается до вызова процедуры, счетчик = 0, передается в процедуру по интерфейсу, счетчик увеличивается до единицы. Процедура завершается, счетчик уменьшается до нуля, объект уничтожается. Все как бы хорошо.

Но, как следствие, с полями (и, видимо, с переменными) это не прокатывает.

Кстати, что происходит в C++-ных ARC-объектах в таких случаях (создание in-place и тут же передача в процедуру)?

В C++ за то, будет у тебя подсчет или нет, отвечают ссылки. Соответственно, если принимаешь на вход shared_ptr, то утечки не будет. Если принимаешь сырой указатель и кто-то передал туда результат new, то будет утечка.

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

Qraizer — Mon, 14 Jul 2014 16:03:14 +0000

Qraizer:

Цитата Shaggy @ 14.07.14, 13:31

Цитата Qraizer @ 14.07.14, 10:17

И создаваемый объект уже имеет счётчик 1, что однозначно отличает его состояние "только что создан" от "последняя ссылка освобождена".

что хранит счётчик?... количество ссылок
кто ссылается на создаваемый объект?... никто
чему равен счётчик?... 0

На создаваемый объект ссылается то, что в данный момент владеет его Self-ом. Не знаю, кто этим является в Дельфях, наверно неосязаемое ничто, тогда вопросов, кроме уже поднятых не мною, нет. А вот в Плюсах этим нечто является отнюдь не ничто, а вполне осязаемый объект шаред-поинтера. Возможно временный, если речь идёт о, скажем, возврате по значению из функции, в любом случае инк при инициализации моего объекта и последующий дек в деструкторе временного не дадут счётчику упасть в нуль. Да здравствует семантика значений.
В Дельфи что, в натуре считается нормальным, когда интерфейсы живут сами по себе безо всяких их реализующих объектов? Не запутались там в своих ссылках ещё, нет? Снова вопрошаю: на кой хрен считать интерфейсы?

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

korvin — Mon, 14 Jul 2014 15:23:03 +0000

korvin:

Цитата Shaggy @ 14.07.14, 14:52

Ну тогда вернись к моему первому примеру и объясни какого хрена там вызывается деструктор при выходе из процедуры Build.

приведи свой код, который компилируется и не работает

Совсем запутали вы меня.

program Test;

{$APPTYPE CONSOLE}

{$R *.res}

uses

SysUtils,

Classes;

type

IWriter = interface

procedure Write(S: string);

procedure Flush;

end;

TWriter = class(TInterfacedObject, IWriter)

private

FLines: TStringList;

public

constructor Create;

destructor Destroy; override;

procedure Write(S: string); virtual;

procedure Flush; virtual;

end;

constructor TWriter.Create;

begin

inherited;

FLines := TStringList.Create;

end;

destructor TWriter.Destroy;

begin

FLines.Free;

inherited;

end;

procedure TWriter.Write(S: string);

begin

FLines.Add(S);

end;

procedure TWriter.Flush;

var i: Integer;

begin

for i := 0 to FLines.Count - 1 do

WriteLn(FLines[i]);

end;

var

W: TWriter;

procedure Build(W: IWriter; S: string);

begin

W.Write(S);

end;

begin

W := TWriter.Create;

Build(W, 'Foo');

Build(W, 'Bar');

W.Flush;

W.Free;

ReadLn;

end.

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

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

Shaggy — Mon, 14 Jul 2014 14:52:09 +0000

Shaggy:

Цитата korvin @ 14.07.14, 14:47

Ну тогда вернись к моему первому примеру и объясни какого хрена там вызывается деструктор.

твой пример не компилируется
да, я могу, как ты говоришь, исправить "опечатки"
и я это уже сделал, у меня всё работает
но это уже получился мой пример

приведи свой код, который компилируется и не работает

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

korvin — Mon, 14 Jul 2014 14:47:56 +0000

korvin:

Цитата Shaggy @ 14.07.14, 14:40

ничем

Ну тогда вернись к моему первому примеру и объясни какого хрена там вызывается деструктор при выходе из процедуры Build.

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

Shaggy — Mon, 14 Jul 2014 14:40:10 +0000

Shaggy: ничем