Будут ли параметры const и Typecasting работать, как раньше, под Delphi 64bit? - PullRequest
Новая
       18

Будут ли параметры const и Typecasting работать, как раньше, под Delphi 64bit?

7 голосов
/ 31 января 2011

Как правило, я обходил множество классических ловушек при использовании указателей, используя преимущества константных (нетипизированных) параметров, а не жестко закодированных типов. Это дает мне преимущество в скорости при выполнении расширенных графических функций, оставляя технические детали на усмотрение компилятора. Это также упростило использование одного и того же кода в Delphi и Free Pascal с минимальными изменениями. Однако в последнее время я начал подвергать сомнению это из-за смелых утверждений Embarcadero об эволюции Delphi и ее новой модели безопасности.

Например, рассмотрим следующий пример: 

Type TSomeDataProc = procedure (const aInput;var aOutput) of Object;

(* Convert 8-bit pixel to 16-bit pixel *)
Procedure TMyClass.ProcessSomeData08x565(Const aInput;var aOutput);
var r,g,b: Byte;
Begin
  FPalette.ExportTriplets(Byte(aInput),r,g,b);
  Word(aOutput):=(R SHR 3) SHL 11 or (G SHR 2) SHL 5 or (B SHR 3);
End;

(* Convert 16-bit pixel to 24-bit pixel *)
Procedure TMyClass.ProcessSomeData565x888(Const aInput;var aOutput);
Begin
  With TRGBTriple(aOutput) do
  Begin
   rgbtRed:=(((word(aInput) and $F800) shr 11) shl 3);
   rgbtGreen:= (((word(aInput) and $07E0) shr 5) shl 2);
   rgbtBlue:= ((word(aInput) and $001f) shl 3);
  end;
End;

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

Private
FLookup: Array[pf8bit..pf32bit,pf8bit..pf32bit] of TSomeDataProc;

Procedure TMyClass.Create;
Begin
  Inherited;
  FLookup[pf8bit,pf16bit]:=ProcessSomeData08x565;
  FLookup[pf16bit,pf24Bit]:=ProcessSomeData565x888;
end;

Когда нам нужно конвертировать пиксели, мы просто ищем правильный метод и используем его. Синтаксис остается одинаковым для всех процедур, поэтому нам не нужно беспокоиться о том, «как» работает каждая процедура. Что касается нашего класса, все они выглядят одинаково. 

Procedure TMyClass.ConvertTo(aFormat:TpixelFormat);
Begin
 // Get function for the correct pixel converter
 FConvertProc:=FLookup[CurrentFormat,aFormat];

 //Use the pixel converter
 FConvertProc(GetSourcePixelAddr(x,y),GetTargetPixelAddr(x,y));
end;

Вопрос в следующем: Будет ли этот тип приведения типов (например, Const to Byte или любой определенный тип записи) выживать в 64-битном режиме? Лично я не могу понять, почему нет, но Embarcadero был немного неясен в отношении новой модели «безопасности» и использования указателей, поэтому мне сложно защитить свой код на будущее.

Ответы [ 2 ]

3 голосов
/ 31 января 2011

Поскольку такие трюки используются в RTL, я не вижу, чтобы устаревшие параметры типа var или const были устаревшими без большого количества взлома кода.

Embarcadero старается поддерживать как можно большую обратную совместимость.

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

И такая модификация не будет иметь ничего общего сделать с 64-битной моделью, в то время как ассемблер x86-64 был новым куском кода для написания.

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

1 голос
/ 04 февраля 2011

Обратите внимание, что FPC уже изменил параметр CONST, хотя и не в этом случае.

Для обычного случая CONST больше не гарантируется ссылкой для всех соглашений о вызовах, но следует тому, что указывает соответствующий ABI.Новый тип параметра CONSTREF гарантированно будет ссылочным.

Как и во всех случаях нарушения совместимости, проблема заключается в том, что в TP / Delphi CONST всегда указывается в ref, но TP / Delphi также всегда x86.

Среди прочего меняются все функции STDCALL, например, IUnknown.Queryinterface:

http://wiki.freepascal.org/User_Changes_Trunk#IInterface.QueryInterface.2C_._AddRef_and_._Release_definitions_have_been_changed

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

Обратите внимание, что IUnknown также используется на других платформах, например, для Firefox XPCOM

Delphi.может также натолкнуться на такие препятствия, но я думаю, что они в первую очередь будут влиять на функции / методы с явными требованиями к соглашениям о вызовах, потому что можно изменить внутреннее соглашение в соответствии с потребностями, но практически невозможно изменить остальной мир ((XP) COMили существующие библиотеки C (++) для соответствия существующему коду в Delphi

...