» Вопросы по Embarcadero RAD Studio XE3

RuXandr

Цитата:

Захотелось проверить, быстрее ли TMonitor чем крит. секции. Увы, на XE и XE3 (Win32) крит. секции быстрее ровно в 2 раза.

Любопытно. Надо перепроверить

З.Ы: Кстати, где-то я читал тред про сипны vs крит. секции. В некоторых сценариях спИны разрывают крит. секции на части. Предположу, что вы тестировали самым простым способом а-ля [more]
t1 := GetTickCount или QueryPerf.
for ....
begin
TMonitor.Enter(obj);
TMonitor.Exit(obj);
end;
t2 := GetTickCount или QueryPerf. - t1;
[/more]

Так точно!


[more]
const MAXC = 10000000;

procedure TForm1.Button1Click(Sender: TObject);
var
i: Integer;
cs: TRTLCriticalSection;
dt: TDateTime;
begin
InitializeCriticalSection(cs);
dt := now;
for i := 0 to MAXC - 1 do
begin
EnterCriticalSection(cs);
if i <> 0 then;
LeaveCriticalSection(cs);
end;
Caption := FormatDateTime('hh:nn:ss:zzz', now - dt);
DeleteCriticalSection(cs);
end;

procedure TForm1.Button2Click(Sender: TObject);
var
i: Integer;
dt: TDateTime;
begin
dt := now;
for i := 0 to MAXC - 1 do
begin
MonitorEnter(Self);
if i <> 0 then;
MonitorExit(Self);
end;
Caption := FormatDateTime('hh:nn:ss:zzz', now - dt);
end;
[/more]

вопрос такой:
предположим у меня есть есть класс

Код:
TphTaskControl=class(TInterfacedObject, IphTaskControl)
...
end;

нет. не должно быть.

Self as interface - это все равно self.

Можешь ради интереса сравнить TObject(var-IphTaskControl).ClassName

Цитата:

нет. не должно быть.

Self as interface - это все равно self.

Можешь ради интереса сравнить TObject(var-IphTaskControl).ClassName

попробуй
[more]
program Project10;

{$APPTYPE CONSOLE}

{$R *.res}

uses
System.SysUtils;
type
ISomeInt=interface
['{F6180160-FB7D-4EBF-B93C-F6FD79A284F3}']
function SomeMethod(cmpI:ISomeInt;cmpO:TObject):Boolean;
end;


TSomeType=class (TInterfacedObject,ISomeInt)
function cmp(i1,i2:IInterface):Boolean;
function SomeMethod(cmpI:ISomeInt;cmpO:TObject):boolean;
end;
{ TSomeType }

function TSomeType.cmp(i1, i2: IInterface): Boolean;
begin
result:=i1=i2;
end;

function TSomeType.SomeMethod(cmpI: ISomeInt; cmpO: TObject): boolean;
var o:TObject;
begin
result:=cmp(cmpI, cmpO as TsomeType);
end;

var o:TSomeType;
i:ISomeInt;
c:char;
begin
try
o:=TSomeType.Create();
i:=o;
Writeln(i.SomeMethod(i,o));
ReadLn(c);
{ TODO -oUser -cConsole Main : Insert code here }
except
on E: Exception do
Writeln(E.ClassName, ': ', E.Message);

end;
end.

[/more]
Я наверное, что=то недопонимаю

а если изменить

Код:
function TSomeType.cmp(i1, i2: IInterface): Boolean;
var o1,o2:TObject;
begin
// result:=i1=i2;
o1:=i1 as TSomeType;
o2:=i2 as TSomeType;
result:=o2=o1;
end;

COW у массивов нету. Скорее всего по ссылке, глянь в CPU Window и посмотри
В конце концов пустой дин.массив - это по определению nil. Так что кроме как по ссылке и не должно быть.

Во всяком случае при использовании const/var

http://delphihaven.wordpress.com/2011/07/17/things-that-make-you-go-urgh/
http://delphihaven.wordpress.com/2009/12/04/are-dynamic-arrays-half-baked/

http://docwiki.embarcadero.com/RADStudio/XE3/en/Internal_Data_Formats#Dynamic_Array_Types

Для открытых массивов есть замечание "не взорви стек" - http://docwiki.embarcadero.com/RADStudio/XE/en/Parameters_(Delphi)#Open_Array_Parameters
Для динамических массивов такой заметки нет

Добавлено:

Цитата:

       ReadLn(c);

Между прочим, по определению это эквивалентно

Цитата:

Read(c); ReadLn;

Так нас учат книжки по Паскалю. Дурацкий вопрос - зачем тут Read(c) ?

А вообще у меня XE2, но классы, которые возвращают Self я делал, и использовал готовые так же (из JCL и OTL например)

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


Цитата:

cmp(cmpI as TsomeType, cmpO as TsomeType);

Добавлено:
https://www.google.ru/search?client=opera&q=delphi+interface+equality&sourceid=opera&ie=utf-8&oe=utf-8&channel=suggest

даёт нам среди прочего http://blog.excastle.com/2008/05/10/interfaces-and-reference-equality-beware/

читай секцию "A failed workaround"

и не используй IInterface, потому что все интерфейсы наследуются от него

Добавлено:

Цитата:

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

Generics ? в XE2 констрейнты с интерфейсами ненадежно работает, но в XE3 обещали поправить
http://qc.embarcadero.com/wc/qcmain.aspx?d=111211
http://docwiki.embarcadero.com/RADStudio/XE3/en/Constraints_in_Generics

а так ты хочешь множественное наследование (через общий IInterface - привет проблема ромба), а его в Delphi нет.
http://docwiki.embarcadero.com/RADStudio/XE3/en/Object_Interfaces

Добавлено:
Ну и как всегда есть одно место... https://www.google.ru/search?client=opera&q=delphi+multiple+interface+inheritance&sourceid=opera&ie=utf-8&oe=utf-8&channel=suggest

http://edn.embarcadero.com/article/29779
http://delphi.uservoice.com/suggestions/2700516
http://www.progtown.com/topic340552-multiple-inheritance-of-interfaces-in-delphi.html

Arioch1

Цитата:

даёт нам среди прочего http://blog.excastle.com/2008/05/10/interfaces-and-reference-equality-beware/

(ISomeInt as IInterface)<>Obj as Iinterface. видимо, каждая иерархия реализованных интерфейсов имеет собственную заглушку даже для аналогичных базовых интерфейсов.
А Obj as Iinterface давал мне VMT IInterface , взятую у TInterfacedObject


Цитата:

попробуй сделать равные условия
Цитата:
cmp(cmpI as TsomeType, cmpO as TsomeType);

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




Цитата:

В конце концов пустой дин.массив - это по определению nil. Так что кроме как по ссылке и не должно быть.

Да, определенно. Динамический массив - это ссылочный тип, и с подсчетом ссылок, но без семантики Copy-On-Write, хотя что им мешало сделать как в строках?

Цитата:

Generics ? в XE2 констрейнты с интерфейсами ненадежно работает, но в XE3 обещали поправить
http://qc.embarcadero.com/wc/qcmain.aspx?d=111211

там в QC и не дожно компилится. Чел указывает констрайнт class, а пихает интерфейс. Там констрайнт как раз должен быть IInterface.
Но в целом, учитывая долгое время не правленные баги, Out-Of-Memory, AV, и даже ошибки в кодегене = генерики крайне хреново сделаны во всех версиях. Я уже подумываю соскочить на C++ Builder, благо,
там есть уже нормальный компилятор для 64, и уже не такой тупорылый диалект C++ (кстати, есть ли обзоры о степени реализации стандарта 11 в компиляторах билдера и МС?)

это мой QC, принятый и якобы исправленный
не путайте class и TClass а равно Interface и IInterface
насчет же "пихает интерфейс" - прочитайте справку по вышеприведенной ссылке.
Это не более "неправильно", чем делать record helper для строк и множеств

ISomeInt as IInterface == ISomeInt


Цитата:

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

1) иерархия одна единственная - IInterface и все, что из него выросло. Других иерархий нет по определению.
2) Заглушек в интерфейсах нет - есть только указатели на процедуры
3) Соответсвенно там ничего нет "для базовых интерфейсов" - а только все более наращиваюися список указателей на методы.

Вы понимаете чем virtual-методы классов отличаются от dynamic-методов?
Так вот, интерфейсы - они не dynamic, они virtual.

Учитывая политику Эмбы, если соскакивать на C++ - то лучше сразу брать от какой-то надежной фирмы (MS, Intel), или же изначально общий floss-проект (CLang? GCC?)

А Эмба уже столько начудила, что если ее вообще перестанут покупать и она закорется через пару лет - не удивлюсь. Хотя и слегка пожалею.


Добавлено:

Цитата:

но без семантики Copy-On-Write, хотя что им мешало сделать как в строках?

Вообще говоря, строки - это не только COW


Цитата:

@StringVar[20]

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

Теперь представим array of TSomeObj
Допустим, мы копируем этот массив. Как копировать объекты в отсутствие в Дельфи copy constructor ?
А если каждый объект монопольно блокирует какой-то файл - как его вообще копировать ?
А если этот массив занимает 1,5 ГБ памяти - как его копировать ? И сколько времени это займёт?

А копировать придется при любом взятии адреса любого элемента.

Далее, представим array of record o: TSomeObj; i: ISomeIntf; end;
Как такое копировать ?

Цитата:

не путайте class и TClass а равно Interface и IInterface
насчет же "пихает интерфейс" - прочитайте справку по вышеприведенной ссылке.

да в справке - просто ссылочный тип, а реализация на практике - настоящий класс. Имхо, и правильно. Класс написано, значит класс должен быть. А если нужон интерфейс - так пиши констрайнт туда IInterface, любой интерфейс прокатит. Кто блин читает справку?


Цитата:

2) Заглушек в интерфейсах нет - есть только указатели на процедуры

указатели на заглушки, там они непрямые же. Ну и саму таблицу именую - заглушка.


Цитата:

3) Соответсвенно там ничего нет "для базовых интерфейсов" - а только все более наращиваюися список указателей на методы.

ну если
TSomeObj=class(TInterfacedObject, ISomeInt)
то списка будет два. Первый принадлежит TInterfacedObject, там таблица на IInterface, и второй список для ISomeInt. Унаследованная таблица, от TInterfacedObject, я считаю, не соглашаясь с вами, как раз и не наращивается. Создается новая. Вот отсюда и пример вышеприведенный.

Цитата:

Цитата:

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

1) иерархия одна единственная - IInterface и все, что из него выросло. Других иерархий нет по определению.

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

Цитата:

Цитата:
@StringVar[20]
уже приводит к вызову UniqueString

хуже того, PChar(Str) тоже приводит. Так что я часто делаю PChar(Pointer(str)) для api - это срабатывает на ура. и для WideString тож


Цитата:

Теперь представим array of TSomeObj<...> Как такое копировать ?

соглашусь.

хотя разве нет копирующих ctor сейчас в Delphi?

.

AlekXL

Цитата:

хотя разве нет копирующих ctor сейчас в Delphi?

Их и не было.

Друзья! давайте вновь окинем взором RO, хоть я и зарекался не смотреть в его сторону. НО!
Здесь Марк выложил свое новое нугатворение: _http://blogs.remobjects.com/blogs/mh/2013/03/11/p5663
Глядя на исходники _https://github.com/dwarfland/TicTacToe (крестики-нолики) у меня зашевелились волосы на ***** и возник резонный (для меня) ВОПРОС
- почему так много КОДА? для такой весьма незатейливой игры?
Варианты:
1) Так и должно быть для object-c стиля программирования это норма
2) Так не должно быть, все мудреность возможно от скрещивания паскаля и обжект-с методом "оксигенной" инженерии
3) Это вообще норма для mvc-го подхода - ты откуда вылез вообще, сейчас все так пишется
4) Кода на самом деле в самый раз - у меня разыгралось воображение
Какие у вас мнения, господа?

sergionn

Цитата:

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

Я за этот вариант. Имхо, всё чисто ППЦшное ... и даже без глазури

Хотя, может, автор хотел какие-то супер-пупер удобные конструкции/подходы показать в этом абсолютно диком, не читаемом коде

[more]что с форумом? что за тормоза? ддосят?[/more]

sergionn
Eternal_Shield

На Delphi было бы короче? Незатейливая игра умеет играть через GameCenter на двух дивайсах. Как бы вы делали сетевую пошаговую игру?

Ну и про количество кода. Есть пять файлов:

1) AppDelegate - стандартный делегат iOS-приложения, кода почти нету (делается шаблоном iOS приложения);

2) Board - кастомный iOS контрол для игровой доски.

3) ComputerPlayer - код для компьютерного игрока (типа, AI)

4) Program - код из шаблона iOS приложения (точка входа, типа .dpr) - кода почти нету;

5) RootViewController - основная логика GUI + делегаты для реализации сетевой пошаговой игры через GameCenter.

Где именно много кода? Ну, кроме шуток - чего в этой проге непонятного??

deks

Цитата:

На Delphi было бы короче?

Как раз таки сетевая составляющая - это пара строк и 1 делегат (типа обработчик обновлений). Вот и вся сетевая игра ... правда, я не в курсе, что за GameCenter. Какой-то рандеву сервер, чтобы с p2p не сношаться? В общем-то, не суть;

Объём кода великоват. Возможно я что-то недооцениваю или, наоборот, переоцениваю ... [more]но, в целом, имхо, от этого кода несёт ппцностью за версту[/more] Есть вероятность, что аналог на Delphi может получиться и более объемный, а может и нет; Проверять нет времени;

[more]После месяца развлекухи с "кислородом" ... я понял, что это высоко концентрированный углекислый газ с каким-то ароматизатором;[/more]

deks
мне тоже показалось, что GameCenter должен взять на себя сетевую часть, как верно подметил Eternal_Shield в пару-тройку строк.
Про Ai в крестиках-ноликах я скромно промолчу.
А вообще раз ты говоришь что это теперь норма для таких вещей, тогда ой.
Я 15 лет не программировал, сейчас наверстываю упущенное.
От экосистемы object-c я в ужасе, думал оксиген сгладит переход,
но мне кажется он усугубляет все, главный вопрос: на чистом object-c все было бы в таком же объеме?

А вообще как я заметил, неумолимая тенденция к ИЗЛИШНЕМУ усложнению технологий и реализаций
свойственна не только ИТ, все со временем становится сложнее и сложнее, все увязают как в болоте,
потом бац, кто-то посмотрел на вещи новым взглядом, откинул все лишнее, и вот - рождение новой звезды!

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

Разбавим священные войны...

Попробуйте в XE3 вот эту программку: qc.embarcadero.com/wc/qcmain.aspx?d=113671

в Delphi 2006 работает правильно.

Arioch1
И в чём проблема? [more] [/more]

AS. А картинки зачем? текст скопировать нельзя было ?

в xe2 первый три строчки будут
Цитата:

'@' is: 64

Потому что '@' - это varInteger :-[..]

Arioch1

Цитата:

AS. А картинки зачем? текст скопировать нельзя было ?

Нет нельзя, ибо не православно


Цитата:

в xe2 первый три строчки будут

Ну...и? Какая там связь с ХЕ3?

Eternal_Shield
sergionn

GameCenter от Apple - это типа OpenFeint, Origin, Crystal: внутри-игровая социальная сеть (друзья, достижения, таблицы результатов и тп). Для пошаговых игр есть возможность сделать игру или с другом, или со случайным человеком (который готов играть в ту же игру). подробнее марк писал в блоге (_http://blogs.remobjects.com/blogs/mh/2013/03/11/p5663). И для взаимодействия с GameCenter нужна не пара строчек, а чуть побольше. Думаю, у досовской программы на C++таких возможностей не было Взаимодействию с GameCenter посвещен ровно один файл из трех с кодом. Разбиение на файлы в Objective-C по классу (ну и вспомогательные классы к основному) на файл - это так принято, типа как с формами на дельфи.

По поводу избыточной графомании под Objective-C: программа на Oxygene один в один как на Objective-C, только синтаксис чуть приятнее (нет квадратных скобок, пара плюшек с синтаксическим сахаром). В TicTacToe не использовалось никакого RTL от Oxygene - только нативные средства iOS. Зачем тогда Oxyegen? Ну, пару файлов ( AI + некоторую логику игры) можно перенести под Android - тупо использовать на другой платформе!

Цитата:

Нет нельзя, ибо не православно

Ещё одна строчка в кондуит православия :-D


Цитата:

Ну...и? Какая там связь с ХЕ3?

Простая - у меня нет XE3, вот и спрашиваю протестить как там.
Кстати, перечитай QC. Это уже забавно.

Этот баг сообщили еще в 2009, но вместо того, чтобы исправить, его, как водится, просто закрыли.
"Вы смогли обойти наши баги ? ну значит это и не баги вообще"
"Вот когда убьют - тогда и приходите"

И еще, если твой отчёт правильный - то значит в XE3 его втихую поправили. Но про это не знают не QC ни QA Team.

Пойду за попкорном. Читать QC инетреснее, чем смотреть Дом 2

Цитата:

'@' is: 64

нет такого в xe3. ни 32, ни 64-bit. Видимо где-то добавили еще один баг, и он случайно исправил прежний.

У меня вопрос, может, уже задавал: существует ли готовый класс, библиотека для Overlapped IO? Или файловый IO CP?

И еще: вот есть метод _Release класса TInterfacedObject, реализующий метод интерфейса IInterface, как я полагаю. То есть по сути, он виртуальный. Мне нужно , чтобы класс , унаследованный от TInterfacedObject гарантированно перехватывал все виртуальные вызовы _Release, несмотря на то, что _Release объявлен в базовом статически.

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

То есть Delphi допускает как статическую реализацию методов интефейса, так и полиморфную.
Как, интересно, дела обстоят в C++ с этим?

Arioch1

Цитата:

И еще, если твой отчёт правильный - то значит в XE3 его втихую поправили. Но про это не знают не QC ни QA Team.

Походу, в Ем-ро вообще все сами по себе. Как-то раз, Япошка из QC мне вообще следующее задвинул: у нас есть Internal QC трэкер и он никак не коррелирует с основным Там всё что надо закрыто, а до "внешнего" QC руки не доходят ... ТруЪ? das ist ТруЪ!


Цитата:

Пойду за попкорном. Читать QC инетреснее, чем смотреть Дом 2

Попкорну не хватит

AlekXL

Цитата:

вот, разобрался.

Грац. Р-р-растёте!


Цитата:

Как, интересно, дела обстоят в C++ с этим?

А что, в C++ уже появились интерфейсы?

Цитата:

И еще: вот есть метод _Release класса TInterfacedObject, реализующий метод интерфейса IInterface, как я полагаю. То есть по сути, он виртуальный. Мне нужно , чтобы класс , унаследованный от TInterfacedObject гарантированно перехватывал все виртуальные вызовы _Release, несмотря на то, что _Release объявлен в базовом статически.

Обломись, моя черешня.

во-первых любой потомок может заново реализовать интерфейс и заново указать другие реализующие методы.

во-вторых в отличие от .net, в Delphi/x86-x64 каждый интерфейс наследуется от IInterface, поэтмоу каждый интерфейс - в соответствии с заветами COM - содержит свои, независимые _AddRef и _Release.
Именно поэтому невозможно множественное наследование интерфейсов в нативнйо Дельфи.



Цитата:

у нас есть Internal QC трэкер и он никак не коррелирует с основным

и не один, судя по косвенным

Arioch1

Цитата:

во-первых любой потомок может заново реализовать интерфейс и заново указать другие реализующие методы.

нет, не может, как я считаю. Реально, практически - не может.
[more]program Project15;

{$APPTYPE CONSOLE}

{$R *.res}

uses
System.SysUtils,System.Classes;
type
IMyInterface=interface
procedure SomeMethod();
end;

TMyClass=class(TInterfacedObject,IMyInterface,IInterface)
procedure SomeMethod();
function _Release():integer;
function IMyInterface._Release=_Release;//
function IInterface._Release=_Release;//
end;

{ TMyClass }

procedure TMyClass.SomeMethod;
begin
//
end;

function TMyClass._Release: integer;
begin
//
end;

begin
try
{ TODO -oUser -cConsole Main : Insert code here }
except
on E: Exception do
Writeln(E.ClassName, ': ', E.Message);
end;
end.
[/more]
как вот покажите на примере, как можно можно переопределить метод _Release в TMyClass, чтобы при манипуляциях с IMyInterface вызывался именно он, а не TInterfacedObject._Release. Я думаю, не сможете, и ваша самоуверенность вас подведет.

И в чём проблема, хоть я и не (кровь и души) Ариох?

Код:
{$APPTYPE CONSOLE}

{$R *.res}

uses
System.SysUtils,System.Classes;
type
IMyInterface=interface
['{A0CBB24B-DF8E-411E-A7AD-A879AEADD8D2}']
procedure SomeMethod();
end;

TMyClass=class(TInterfacedObject,IMyInterface,IInterface)
public
procedure SomeMethod();
function _Release(): integer; stdcall;
function IMyInterface._Release=_Release;//
function IInterface._Release=_Release;//
end;

{ TMyClass }

procedure TMyClass.SomeMethod;
begin
//
end;

function TMyClass._Release: integer;
begin
Writeln('Test');
Result := inherited _Release;
end;

var
i: IMyInterface;
begin
i := TMyClass.Create as IMyInterface;
try
ReadLn;
except
on E: Exception do
Writeln(E.ClassName, ': ', E.Message);
end;
end.

AlekXL

Цитата:

как вот покажите на примере, как можно можно переопределить метод _Release в TMyClass, чтобы при манипуляциях с IMyInterface вызывался именно он, а не TInterfacedObject._Release. Я думаю, не сможете, и ваша самоуверенность вас подведет.

[more]
program Project4;

{$APPTYPE CONSOLE}

{$R *.res}

uses
System.SysUtils;

type
ILOLO = interface
procedure SomeMethod;
end;

TROLOLO = class sealed (TInterfacedObject, ILOLO)
public
function _Release: Integer; stdcall;
procedure SomeMethod;
end;

{ TROLOLO }

procedure TROLOLO.SomeMethod;
begin
{ SomeMethod }
end;

function TROLOLO._Release: Integer;
begin
WriteLn('Святой Иисус-водопроводчик!');
end;

var
I: ILOLO;

begin
try
I := TROLOLO.Create;

I := nil;
ReadLn;

{ TODO -oUser -cConsole Main : Insert code here }
except
on E: Exception do
Writeln(E.ClassName, ': ', E.Message);
end;
end.
[/more]

Вуаля, нет терь вызова TInterfacedObject._Release...Ну и?

меня смутило слово " перехватывал "

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

потому что ваши примеры... это не перхват, это обычная реализация метода.

перехват - это всё же то, что делается вместо стандартного исполнения. Hook, interception...