Eternal_Shield Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору HeMet Цитата: Нужно использовать TDictionary<string, T>. Врят ли найдётся человек, который будет использовать TStringList.AddObject('a', Pointer($1)) вне известных компонентов (TMemo, TCombobox и т.п) Всего записей: 766 | Зарегистр. 18-05-2009 | Отправлено: 10:46 17-06-2013 | Исправлено: Eternal_Shield, 10:46 17-06-2013

Arioch1 Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: почем нельзя "достать" из объекта, который поддерживает IChild родительский интерфейс IParent?   diamond problem   Код: IParent=interface    end;        ISon=interface(IParent)    end;    IDaughter=interface(IParent)    end;     TChild=class(TInterfacedObject, ISon,IDaughter);   i_parent := IParent(TChild.Create); // which one ???     Добавлено: Цитата: который будет использовать TStringList.AddObject(   сейчас - да. а когда дженериков не было ? Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 12:16 17-06-2013

deks Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Arioch1   Ну - какой интерфейс IParent реализуется объектом TChild, такой и доставать!     Не забываем, что проблема "ромбовидного" наследования характерна именно для множественного наследования полноценных объектов, то есть там, где есть РЕАЛИЗАЦИЯ методов базового класса, которая может быть различна у потомков.     А вот интерфейс - это как бы АБСТРАКТНЫЙ класс, без реализации.     Поэтому все упрощается:  в указанном примере все будет ок, вся неоднозначность должна быть снята при реализации TChild, мы просто укажем явно как именно реализовывать IParent.     Добавлено: ego666   Цитата: Убогость в твоей логической цепочке. Ещё раз: TList выполняет ровно то, что в него заложено, но если бы он вообще был ни на что негоден, то тогда можно было бы говорить о убогости.   Убогость в том, что TList мог бы выполнять гораздо больше путем простой метки "virtual" у методов. Причем, причины отсутствия этой метки не ясны. И убогость в том, что он может выполнять ТОЛЬКО ТО что в него заложено, а изменить поведение не получится. Если тебе кажется что менять поведение стандартных контейнеров нет смысла - ну и живи с этим чувством! Я ж не спорю с твоим мироощущением - ты имеешь на него полное право. Видимо, по существу означенной проблемы ты возразить не можешь: TList не может менять свое поведение.     Ну и я никогда не говорил "TList ни на что не годен". Если бы он не мог выполнять то, что в него заложено - стоило бы говорить не об убогости, а о неработоспособности.     Еще раз: есть задача изменить поведение TList. Подробнее: есть реализованный на его базе список файлов в каталоге. Список с отложенным чтением самого каталога (чтобы объект создавался быстро), но по доступу, например к свойству Count этот список читается. Вопрос: как реализовать это на TList?     Мой ответ: никак! По непонятной причине методы TList не виртуальные, нужно делать собственную реализацию. У этого подхода огромный недостаток -  для любых посторонних объектов, которые умеют работать с TList, собственная реализация не подходит!   Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 12:25 17-06-2013

deks Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Eternal_Shield   Хм. А чем дельфовый интерфейс концептуально отличается от абстрактного класса? Ну, кроме возможности реализовать много интерфейсов одним классом? Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 16:12 17-06-2013

valgreesh Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Arioch1 Цитата: Другими словами интеропа - нет, он не обеспечен ни проблемно, ни тем более беспроблемно (но есть теоретическая возможность его обеспечить и COM VTBL этому как-то поможет) Интероп с win32 обеспечен таки беспроблемный (для буквоедов добавлю - при условии использования ограниченного количества типов и прочее бла-бла) (мы можем получить интерфейс извне и использовать его привычным образом - Direct2D, например. Мы можем отдать интерфейс во вне и его смогут использовать). Что же касается Objective-C... Чем являются тамошние протоколы, если не абстрактными классами из C++ -> интерфейсами? Всего записей: 292 | Зарегистр. 30-11-2011 | Отправлено: 16:42 17-06-2013

AlekXL Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Еще раз - TList<T> невозможно расширить так, чтобы изменить поведение - в этом имхо убогость его архитектуры. В .NET/Java/ObjC можно менять поведение, а в Дельфи нет ну брось. Это всего лишь вариант реализации. Юзай Delphi.Collections. Там все  есть.     Добавлено: Я вот понять не могу.. Если я пишу код для ios, и подключаю внешнюю нестандартную(скажем,C++) библиотеку, то как это все может работать в эмуляторе, если эмулятор работает по x86, а устройство - на ARM?   Мне что, нужно два варианта библиотеки? И получается, отлаживать 1-в-1 можно только подключив ios устройство? И еще вопрос. В лазаре вообще нет отладчика для ios, или андроида? Всего записей: 792 | Зарегистр. 24-04-2008 | Отправлено: 17:17 17-06-2013

deks Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору AlekXL   Цитата: Юзай Delphi.Collections Можно и его, там есть - не спорю. Мне не понятно, почему в TList нету - и обидно, что контролы заточенные под TList с ходу не едят альтернативы! На ровном месте пустые хлопоты..   Цитата: как это все может работать в эмуляторе   Для эмулятора все компилируется для x86, для устройства - в armv7, armv7s. И приложение, и библиотеки. И да, без устройства отладить приложение не получится - производительность эмулятора в x86 и arm на устройстве может ОЧЕНЬ СИЛЬНО отличаться. К тому же на эмуляторе есть/были ограничения в поддерживаемых фичах (Game Center, iCloud, etc). Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 19:01 17-06-2013

Arioch1 Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Интероп с win32 обеспечен таки беспроблемный причем еще в Delphi 2.0   Цитата: Что же касается Objective-C... Чем являются тамошние протоколы Не знаю и знать не хочу Мне обещали УЖЕ реализованное БЕСПРОБЛЕМНОЕ взаимодействие на уровне базовый для языков строительных блоков - объектов   Добавлено: Цитата: А чем дельфовый интерфейс концептуально отличается от абстрактного класса? Например явным запретом на наследование и поддержкой нескольких парраллельно существующих интерфейсов одной сущностью (I1.Count и i2.Count при этом совсем разные методы)   Цитата: Поэтому все упрощается:  в указанном примере все будет ок, вся неоднозначность должна быть снята при реализации TChild, мы просто укажем явно как именно реализовывать IParent.     Это разумеется. Можно сделать класс, поддерживающий и IParent и IChild, их обоих. Но вопрос-то был - http://forum.ru-board.com/topic.cgi?forum=33&topic=13680&start=340#19 - именно почему так нужно делать, почему IParent не появляется автоматически, при указании IChild Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 19:46 17-06-2013

valgreesh Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Arioch1 Цитата: причем еще в Delphi 2.0 Ценное замечание, особенно если учесть, что речь об интерфейсах...   Цитата: Мне обещали УЖЕ реализованное БЕСПРОБЛЕМНОЕ взаимодействие на уровне базовый для языков строительных блоков - объектов Никто таких глупостей не обещал. Всего записей: 292 | Зарегистр. 30-11-2011 | Отправлено: 23:11 17-06-2013

Arioch1 Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: Ценное замечание, особенно если учесть, что речь об интерфейсах... Не совсем, речь о том, что якобы интерфейсы обеспечили возможность использования win32   Цитата: Никто таких глупостей не обещал. Цитата:  обеспечивается беспроблемный интероп с ... Objective C ... кодом   Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 08:36 18-06-2013

Eternal_Shield Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору ego666 Цитата: Вот пример как это может вылезти боком:   Интересно, что этот пример демонстрирует? Почему TFileList не унаследован от TList? Тогда будут доступны интерфейсы IList и IFileList из TFileList и не надо будет реализовывать дополнительно методы IList в TFileList   Да и с каких это пор родитель (в вашем случае IList) обязан знать, что добавлено в наследниках (IFileList) и, главное, по какому такому святому правилу? Вот это уже реальным  бредом пахнет, а не то, что Вам пытался донести deks с проблемами TList<>, но как об стенку горохом Всего записей: 766 | Зарегистр. 18-05-2009 | Отправлено: 11:44 18-06-2013 | Исправлено: Eternal_Shield, 11:49 18-06-2013

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Вопросы по Embarcadero RAD Studio XE4

Переход по форумам  Закладки   » Компьютеры Цифровое изображение Программы Microsoft Windows UNIX Другие OS Hardware В помощь сисадмину Прикладное программирование Игры Форумные игры   » Интернет Web-программирование В помощь вебмастеру Графика Хостинг Зацените-ка!   » Тематические Ikonboard v.2 Ikonboard v.3 Invision Board Другие форумы PHP-Nuke и другие порталы Мобила   » Общие Спорт Флейм Темы по региональным встречам Музыка и Кино Юмор Литература и Живопись   » Ru.Board Новости Помощь по форуму   » Андеграунд eBookz Варезник Раздачи и акции Мобильный варезник Андеграунд Игры и фильмы   » Специальные Тестирование