Ru-Board.club
← Вернуться в раздел «Прикладное программирование»

» Вопросы по Embarcadero RAD Studio XE5-XE8,10.x(Seattle, Berl

Автор: A_V
Дата сообщения: 03.03.2014 19:41
deks

Цитата:
Скажите - а для этих "старых" объектов существует такое понятие, как конструктор? Как они создаются?

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

Цитата:
вряд ли я стал бы это использовать, но в целях повышения квалификации, и ради академического интереса: выкладывай, конечно!

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

код такой:
[more=RecordInterceptor.pas]

Код:
unit RecordInterceptor;

interface

uses System.TypInfo, System.SyncObjs, System.SysUtils, System.Classes;

type
TInitRecordCallBack = procedure(AStackPtr: Pointer; ATypeInfo: PTypeInfo; AIsInit: Boolean) of object;

TMemPatcher = record
type
PJump = ^TJump;
TJump = packed record
OpCode: Byte;
Distance: Cardinal;
procedure Init(ASource, ADest: Pointer); inline;
end;
const
JUMP_SIZE = SizeOf(TJump);
class procedure AddressPatch(ASource, ADestination: Pointer; var AOldCode: TJump); static; inline;
class procedure AddressUnPatch(ASource: Pointer; const AOldCode: TJump); static; inline;
end;

TInitRecordPatcher = record
strict private
type
TInitRecProc = procedure(p: Pointer; typeInfo: Pointer);
class var
CS: TCriticalSection;
OldInitCode, OldFInitCode: TMemPatcher.TJump;
OldInitRecordProc, OldFinitRecordProc: TInitRecProc;
CallBackList: TArray<TInitRecordCallBack>;
class procedure NewInitRecord(p: Pointer; typeInfo: Pointer); static;
class procedure NewFinitRecord(p: Pointer; typeInfo: Pointer); static;
class procedure PerformCall(AStackPtr, ATypeInfo: Pointer; AOldProc, ANewProc: TInitRecProc;
AIsInit: Boolean; AOldCode: TMemPatcher.TJump); static; inline;
class function InitRecordProcAddress: Pointer; static;
class function FinitRecordProcAddress: Pointer; static;
private
class procedure Init; static;
class procedure Finit; static;
public
class procedure RegisterInitRecordCallBack(ACallBack: TInitRecordCallBack); static;
// class procedure UnRegisterInitRecordCallBack(ACallBack: TInitRecordCallBack); static;
end;


implementation

uses Winapi.Windows;

{ TMemPatcher }

{ TMemPatcher.TJump }

procedure TMemPatcher.TJump.Init(ASource, ADest: Pointer);
begin
Distance := Cardinal(ADest) - Cardinal(ASource) - JUMP_SIZE;
OpCode := $E9; //jmp
end;

class procedure TMemPatcher.AddressPatch(ASource, ADestination: Pointer;
var AOldCode: TJump);
var
LJump: PJump absolute ASource;
LOldProtect: Cardinal;
begin
if VirtualProtect(ASource, JUMP_SIZE, PAGE_EXECUTE_READWRITE, LOldProtect) then
try
AOldCode := LJump^;
LJump.Init(ASource, ADestination);
FlushInstructionCache(GetCurrentProcess, ASource, JUMP_SIZE);
finally
VirtualProtect(ASource, JUMP_SIZE, LOldProtect, @LOldProtect);
end;
end;

class procedure TMemPatcher.AddressUnPatch(ASource: Pointer;
const AOldCode: TJump);
var
LOldProtect: Cardinal;
begin
if VirtualProtect(ASource, JUMP_SIZE, PAGE_EXECUTE_READWRITE, LOldProtect) then
try
PJump(ASource)^ := AOldCode;
FlushInstructionCache(GetCurrentProcess, ASource, JUMP_SIZE);
finally
VirtualProtect(ASource, JUMP_SIZE, LOldProtect, @LOldProtect);
end;
end;

{ TInitRecordPatcher }

class procedure TInitRecordPatcher.Finit;
begin
TMemPatcher.AddressUnPatch(@OldInitRecordProc, OldInitCode);
TMemPatcher.AddressUnPatch(@OldFinitRecordProc, OldFinitCode);
CS.Free;
end;

class procedure TInitRecordPatcher.Init;
begin
CS := TCriticalSection.Create;
@OldInitRecordProc := InitRecordProcAddress;
@OldFinitRecordProc := FinitRecordProcAddress;
TMemPatcher.AddressPatch(@OldInitRecordProc, @NewInitRecord, OldInitCode);
TMemPatcher.AddressPatch(@OldFinitRecordProc, @NewFinitRecord, OldFinitCode);
end;

class procedure TInitRecordPatcher.PerformCall(AStackPtr, ATypeInfo: Pointer;
AOldProc, ANewProc: TInitRecProc; AIsInit: Boolean; AOldCode: TMemPatcher.TJump);
var
i: integer;
begin
CS.Enter;
try
try
TMemPatcher.AddressUnPatch(@AOldProc, AOldCode);
AOldProc(AStackPtr, ATypeInfo);
for i := Low(CallBackList) to High(CallBackList) do
CallBackList[i](AStackPtr, ATypeInfo, AIsInit);
finally
TMemPatcher.AddressPatch(@AOldProc, @ANewProc, AOldCode);
end;
finally
CS.Leave;
end;
end;

class procedure TInitRecordPatcher.NewInitRecord(p: Pointer; typeInfo: Pointer);
begin
PerformCall(p, typeInfo, @OldInitRecordProc, @NewInitRecord, True, OldInitCode);
end;

class procedure TInitRecordPatcher.NewFinitRecord(p: Pointer; typeInfo: Pointer);
begin
PerformCall(p, typeInfo, @OldFinitRecordProc, @NewFinitRecord, False, OldFinitCode);
end;

class function TInitRecordPatcher.InitRecordProcAddress: Pointer;
asm
{$IFDEF CPUX86}
lea eax, System.@InitializeRecord
{$ELSE}
lea rax, System.@InitializeRecord
{$ENDIF}
end;

class function TInitRecordPatcher.FinitRecordProcAddress: Pointer;
asm
{$IFDEF CPUX86}
lea eax, System.@FinalizeRecord
{$ELSE}
lea rax, System.@FinalizeRecord
{$ENDIF}
end;

class procedure TInitRecordPatcher.RegisterInitRecordCallBack(ACallBack: TInitRecordCallBack);
begin
SetLength(CallBackList, Succ(Length(CallBackList)));
CallBackList[High(CallBackList)] := ACallBack;
end;

initialization
TInitRecordPatcher.Init;

finalization
TInitRecordPatcher.Finit;


end.
Автор: sergionn
Дата сообщения: 03.03.2014 20:37
deks
создай пожалуйста ветку для remobjects, там "потрем", а то в "чужой" теме как-то не комфортно.....
Автор: kaz_av
Дата сообщения: 03.03.2014 21:24
HeMet

Цитата:
Наверное, всё-таки, без (w/o - without).

Там говорится, что их аппа CrossBox (это мост между VS и OS X, аналог Embarcadero Platform Assistant, насколько я понимаю) будет собрана без зависимостей к Mono и без переписывания аппы под "for Cocoa" компилятор (т.е. Objective-C) Это значит, либо Sugar уже покрывает все потребности CB по части RTL, либо что-то другое (может компилирует сборки mono в бинарные сборки, по типу Xamarin).

sergionn
Для отдельной ветки маловато новостей, а тут все равно обсуждать уже нечего. Все в ожидании XE6
Автор: V1s1ter
Дата сообщения: 03.03.2014 21:54
Alexzzy
Нет переводить не нужно. Надо понимать что новое. Например синтаксис TArray<Byte> говорит о полноценной поддержки шаблонов как С++ или просто "новомодный" синтаксис array of Byte? В record вроде что то добавили, и т.п.

Добавлено:
Alexey_Gawrilow
Огромное спасибо, что то по началу пропустил Ваш пост. Это то что "спасет отца Российской демократии".
Автор: Alexey_Gawrilow
Дата сообщения: 03.03.2014 22:10

Цитата:
A_V


Цитата:
код такой:


Прикольно.
Мне такие штуки нравятся.
+1
Автор: sergionn
Дата сообщения: 03.03.2014 22:46

Цитата:
Это значит, либо Sugar уже покрывает все потребности CB по части RTL, либо что-то другое

я так понял, что другое - этот как раз и будет IDE под OSX, поэтому crossbox никто переписывать не будет, т.к. надобность в нем отпадет вообще
Автор: kaz_av
Дата сообщения: 03.03.2014 23:19
sergionn

Цитата:
crossbox никто переписывать не будет, т.к. надобность в нем отпадет вообще

Там же ясно написано:

Цитата:
i expect and hope that CrossBox will be a native mac app

т.е. никуда он не денется. Да и отказываться от интеграции с VS глупо т.к. не все разработчики под OS X сидят на маках.
Автор: sergionn
Дата сообщения: 03.03.2014 23:35

Цитата:
i expect and hope that CrossBox will be a native mac app

читай дальше и между строк


Цитата:
не все разработчики под OS X сидят на маках.

да-да я помню, и ТЕСТИРУЮТ свои osx app'ы через жопу облачный сервис...
Интересно они CrossBox вместе с за-стомеговым monoruntime куда ставят, тоже в облако?
Я надеюсь, что разновидность клоунов-ретроградов, которые пишут софт для галочки под osx, не ставя хотя бы "виртуальную ось", не смогли перебраться под oxygene....
Автор: HeMet
Дата сообщения: 04.03.2014 07:45

Цитата:
да-да я помню, и ТЕСТИРУЮТ свои osx app'ы через жопу облачный сервис...

Думаю, имелось в виду, что не все кодят из под Mac OS X, а не "никто не тестирует на яблочной технике".
Автор: AnViSe
Дата сообщения: 04.03.2014 07:56
Не поделится ли многоуважаемый All линком на книгу Marco Cantu - Delphi XE Handbook?
Автор: kaz_av
Дата сообщения: 04.03.2014 08:59
sergionn

Цитата:
да-да я помню, и ТЕСТИРУЮТ свои osx app'ы через жопу облачный сервис...

Есть и другие варианты: хакинтош, виртуалка. И если для мобильного софта без девайса не обойтись (конечно если не считать облачный сервис полноценной заменой смарту ), то десктопная ОС прекрасно работает в виртуалке и для тестирования самое то. Ну и не известно, как по удобству их IDE будет в сравнении со студией. Кроме того, CrossBox, может быть, научат работать в обратном направлении т.е. разработка под OS X в их IDE, а запуск и отладка на Windows , домыслы, конечно, но кто его знает. Поживем - увидим
Автор: deks
Дата сообщения: 04.03.2014 10:21
kaz_av
sergionn

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

Про кроссбокс - из слива явно следует, что планируется какой то способ использования .NET под Cocoa без Mono. Вроде, Sugar пока не тянет - хотя хз, там довольно много чего есть! Но API пока бедновато.

Про IDE под OSX - называется эта штука Fire, даже где-то пробегали скриншоты. но, боюсь, будет в первых версиях такой же унылой как MonoDevelop. Я бы для IDE брал за основу хороший состоявшийся проект типа свежего Atom от GitHub.
Автор: kaz_av
Дата сообщения: 04.03.2014 11:29
deks

Цитата:
из слива явно следует, что планируется какой то способ использования .NET под Cocoa без Mono

Из процитированного тобой, что-то не очень следует...

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


Цитата:
Я бы для IDE брал за основу хороший состоявшийся проект типа свежего Atom от GitHub.

Browser based IDE? Это чтоб весь пар современных процессоров вышел в свисток? Кстати говоря, между редактором и IDE не просто пропасть, там целая вселенная.
Автор: sergionn
Дата сообщения: 04.03.2014 12:13

Цитата:
Кстати, на счет водорода, моно-ксамаритянин уже высказал свое фи

теперь мексикашка думает только о бабосах, и появление водородного конкурента расценивает как и все его новые друзья капиталисты - "прямую и явную угрозу" бизнесу, он и не то еще напишет...........
Автор: HeMet
Дата сообщения: 04.03.2014 12:51

Цитата:
теперь мексикашка думает только о бабосах

А RemObjects, когда делали Водород, о чём думали, о всеведующий? Мигель свою точку зрения подкрепил примером с дженериками - их там нет. Поэтому интересно с какой версией c# у них там почти полная совместимость.
Автор: sergionn
Дата сообщения: 04.03.2014 13:33

Цитата:
А RemObjects, когда делали Водород, о чём думали, о всеведующий?

если тебе не знакомы основы стратегического планирования, о непонимающий, то могу намекнуть, что в ПЕРВУЮ очередь они могли ДУМАТЬ об экспансии на смежную платформу,
а затем, УЖЕ после ОЦЕНКИ результатов сего мероприятия можно подумать и о деньгах.
Наверное также думал Мигель, когда создавал Mono - сначала разработать действующую платформу, ПРИВЛЕЧЬ пользователей, а после начать ПОЛНОЦЕННУЮ ее монетизацию - Xamarin.
Никакого альтруизма и поисков ИСТИНЫ в виде указания на поддержку начальных спецификаций - just business, just money.
Автор: Alexey_Gawrilow
Дата сообщения: 04.03.2014 17:27
HeMet

Цитата:
Мигель свою точку зрения подкрепил примером  с дженериками - их там нет


Announcing Elements: Oxygene 7 and RemObjects C#

Цитата:
RemObjects C# is a 100% true and ECMA—spec conform implementation of the C# language



Цитата:
стр.52


Цитата:
8.16 Generics
C# allows classes, structs, interfaces, and methods to be parameterized by the types of data they store and
manipulate. This feature is really a set of features known collectively as generics. C# generics will
immediately be familiar to users of generics in Eiffel or Ada, or to users of templates in C++.


С учетом того, что в "Кислороде" они есть, то есть чуваки умеют,не вижу причин для их исключения в ветке C#.
Автор: deks
Дата сообщения: 04.03.2014 17:31
kaz_av


Цитата:
Из процитированного тобой, что-то не очень следует...


Тут такая тема. Вообще, CrossBox построен как .NET ROSDK Server, а вот в версии ROSDK под Cocoa нету всех необходимых фич для server. То есть, Cocoa инкарнация ROSDK - это кагбэ клиент. Для сервера юзаем .NET/Delphi или уже собранных сервер Relativity. Ну и Delphi версии ROFX у ремобджектов всегда по фичам отставали от .NET ... К чему бы это я? К тому, что едва ли допишут Cocoa Server для ROFX! поэтому единственный вариант появления нативного Cocoa CrossBox - это чего то сделать с .NET версией. Самому интересно - чего.


Цитата:
Browser based IDE?


Почему нет? Если такая архитектура приведет к удобной работе с плагинами, почему бы нет. Благо архитектура довольно глубоко проработана! А насчет редактор / IDE - имхо, дело количественное: когда количество плюшек переходит в качество, продукт называют IDE. Но все таки основная функция IDE - помогать писать программы, а это пока большей степенью делается кодом. Да, инструменты (включая визуальные) - это здорово, но core function любой IDE таки, имхо, редактор.

sergionn

Да, мнение мигеля не совсем адекватное - он сказал что это C# 1.0 типа и вообще дельфи с фигурными скобочками. На самом деле это не так - погорячился! Почему? Хз. Наверное, не очень обрадовался усилению конкуренции. Вдруг MS соскочит с партнерства.. Ну или чего там еще. У ксамарина щас довольно высокие цены - при вменяемой более дешевой альтернативе народ сбежит ($1k за платформу у Ксамарина, у RO $699 за все 3 платформы).

По поводу дженериков: они есть. На Cocoa - с ограничениями ( http://www.elementswiki.com/en/Generics ). Ограничения, видимо, связаны с невозможностью сгенерировать нужный класс из дженерика "на ходу". Поэтому дженерики поддерживаются только для контейнерных типов.

По поводу уровня совместимости с C#: ремобджекты говорят о 100% совместимости, но мне не интересно - я этой штукой не пользуюсь серьезно. Пруф тут - http://www.elementswiki.com/en/Hydrogene_Language

upd: вы будете смеяться, но у Xamarin тоже свои вопросы по дженерикам в Cocoa: http://docs.xamarin.com/guides/ios/advanced_topics/limitations/
Автор: Alexey_Gawrilow
Дата сообщения: 04.03.2014 17:33
kaz_av

Цитата:
Кстати, на счет водорода, моно-ксамаритянин уже высказал свое фи


Что вполне естественно, как конкурента.

RemObjects'у C# нужен для бОлшей пользовательской базы.

При этом RemObjects поддерживает каждую из платформ наиболее "нативно" понимая под нативностью не бинарный код проца, а код платформы.

Не удивит, если через год выкатят Java фронтэнд.
Автор: deks
Дата сообщения: 04.03.2014 17:36
Alexey_Gawrilow


Цитата:
Не удивит, если через год выкатят Java фронтэнд.


Почему нет?) Будем звать из TopSpeed ))) Ну, те - кто помнит!)
Автор: HeMet
Дата сообщения: 04.03.2014 18:18

Цитата:
upd: вы будете смеяться, но у Xamarin тоже свои вопросы по дженерикам в Cocoa:

Каждый день работаю с Xamarin.iOS и невозможность использовать дженерики на obj-c типах не самая его большая проблема. У RO сейчас, по-видимому, куда более серьезные ограничения - только для коллекций.
Автор: Alexey_Gawrilow
Дата сообщения: 04.03.2014 18:27

Цитата:
TopSpeed ))) Ну, те - кто помнит!


Ооо!
Там Modula была!
Там multi-language code!

Автор: HeMet
Дата сообщения: 04.03.2014 18:36
Если верить RO http://www.elementswiki.com/en/Hydrogene_Language и Википедии http://ru.wikipedia.org/wiki/C_Sharp , то они опираются на стандарт c# 2.0.

Общение между Мигелем де Иказа и Марком Хофманом: https://twitter.com/timanderson/status/440507215103811584 . С EMB они пикируются по поводу, что такое native, а с Xamarin теперь будут на тему, что такое 100% compatible Но мне лично больше нравится позиция Мигеля по поводу тех же дженериков: «нету в платформе - сделай сам».
Автор: freepkcat
Дата сообщения: 04.03.2014 19:02
xe5 up2 why?
Автор: deks
Дата сообщения: 04.03.2014 19:37
HeMet

Самые последние новости - более полные дженерики обещаны в следующей бэте
Автор: sergionn
Дата сообщения: 04.03.2014 20:00

Цитата:
Общение между Мигелем де Иказа и Марком Хофманом:

я так понял у мигельки очко жим-жим - в неудачный момент RO "пыхнуло" водородом, т.к. видимо немалые бабосы инвесторов в xamarin ($12M + $16M) не успели принести еще своих бонусов
Хоть мексикашка и подсадил своих "пол-лимона" юзеров на подписку, опасается, что критическая масса проектов не набралась еще, и многие могут соскочить на НАТИВНЫЙ код без прослоек, и менее затратную по деньгам систему.
Вот бы ro напряглась, и проделала это с emb - созерцать последствия было бы большее удовольствие, после "кидка" с обезьяной.........

p.s. HeMet, не становись адептом xamarin'a, оставайся на светлой стороне.......

Добавлено:
Ну вот и свежий роадмап Emb выкатила:
_http://edn.embarcadero.com/article/43677,
если отбросить всю маркетинговую шелуху то в 2014 почти ничего нужного и актуального НЕ СВЕТИТ.

А обещание ИССЛЕДОВАНИЯ на предмет поддержки Windows 8 ARM/WinRT, OSX x64 и Android for Intel АЖ после 2014 - это вообще верх издевательства...
Про ios x64 и android not NEON cpu тоже не слова.......
"Молодцы" абракадебровцы, после выхода этого вдохновляющего роадмапа, рейтинг Дельфи продолжит свое падение.........

Автор: kaz_av
Дата сообщения: 04.03.2014 20:31
deks

Цитата:
Если такая архитектура приведет к удобной работе с плагинами, почему бы нет.

Ты сейчас говоришь о нативных плагинах для браузера? Если так, мне не понятно нафига этот винегрет (JS+нативные плагины) нужен, если можно делать просто отдельный продукт. Какие плюсы будут получены от браузер-основанной IDE?


Цитата:
когда количество плюшек переходит в качество, продукт называют IDE

Ключевым значением для IDE является интегрированность инструментов разработки: редактор кода, отладчик, дизассемблер и прочие прелести. Если это и правда IDE, а не просто продвинутый редактор кода.

Alexey_Gawrilow

Цитата:
Не удивит, если через год выкатят Java фронтэнд.

После чего оракул их засудит и кино закончится

freepkcat

Цитата:
xe5 up2 why?

Because XE6 soon.
Автор: sergionn
Дата сообщения: 04.03.2014 20:44

Цитата:
Какие плюсы будут получены от браузер-основанной IDE?

сейчас тренд такой - все делать в браузере: проги "писать"/собирать, дизайничать, фотки обрабатывать (даже raw уже в браузере переварить "могут"),
главное что под это инвесторы охотно дают денюшку, а то что этими сервисами никто серьезно не пользуется, это уже вопрос тридесятый.
А еще что можно говорить загнув пальцы, что ты теперь в браузере на джаваскрипте все "чикаешь" и иметь всеобщий аттеншн!
Автор: Alexey_Gawrilow
Дата сообщения: 04.03.2014 21:49
kaz_av

Цитата:
После чего оракул их засудит и кино закончится


Это чейта?
Список языков JVM

Я конечно говорил, на RSDN, что основное отличие NET от Java что они (MS) на титул (вперед) выносят платформу, а не язык, и сразу, из горобки, грят, хотите- С#, не хотите - VB, опять нет - J#, F#, JScript.NET.
Совсем не так - IronXXX(IronPython, IronRuby, IronLua, IronPHP далее везде)

И да это основной косяк Java.
То что они двигают, вернее, двигали - "Java это наше фсе".

Выясняется, что нет, не все - просто одна из...платформ.

Добавлено:
kaz_av
? если да, то уважуха, частично читал, нормально
Автор: HeMet
Дата сообщения: 04.03.2014 23:13

Цитата:
я так понял у мигельки очко жим-жим - в неудачный момент RO "пыхнуло" водородом

Опасаться ему стоит пока разве что в перспективе, а пока RO, я так понял, находятся на уровне c# 2.0 да и то не полного.

Цитата:
Хоть мексикашка и подсадил своих "пол-лимона" юзеров на подписку

Не случилось этого. Пользователи сказали, что не катит и они отказались от этой идеи.

Цитата:
и многие могут соскочить на НАТИВНЫЙ код без прослоек, и менее затратную по деньгам систему.

Когда по фишкам их продукты сравняются, тогда цена Водорода будет аргументом за, а пока не очень.

Цитата:
Вот бы ro напряглась, и проделала это с emb - созерцать последствия было бы большее удовольствие, после "кидка" с обезьяной.........

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

Цитата:
p.s. HeMet, не становись адептом xamarin'a, оставайся на светлой стороне.......

Не я у себя на работе решаю на чём кодить. Да и мне не сильно принципиально.

Цитата:
А обещание ИССЛЕДОВАНИЯ на предмет поддержки Windows 8 ARM/WinRT, OSX x64 и Android for Intel АЖ после 2014 - это вообще верх издевательства...

Они же этот релиз хотели багофиксом заниматься, разве нет? Вот поэтому и за 2014, тем более что Windows 8 ARM/WinRT и Android for Intel всё никак не взлетят, а OSX x64 не самое приоритетное для них направление, я думаю.

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129

Предыдущая тема: Отмена встречи в Outlook из Excel VBA


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.