Если вы скомпилируете это:
StrComp(PAnsiChar(Mask.EditText), Val);
Существует неявное преобразование из Mask.EditText как UnicodeString во временное AnsiString, чтобы разрешить приведение типа к PAnsiChar.Это ваша вторая строка:
StrComp(PAnsiChar(AnsiString(MAskEdit.EditText), Val);
Но запись
StrComp(PChar(MAskEdit.EditText), PChar(String(AnsiString(Val))));
позволит PChar(MAskEdit.EditText) вернуть PChar, то есть PWideChar, поэтому он будет использовать другойперегруженная StrComp функция.
На самом деле, с Delphi 2009 в SysUtils.pas определены две перегруженные функции:
function StrComp(const Str1, Str2: PAnsiChar): Integer; overload;
function StrComp(const Str1, Str2: PWideChar): Integer; overload;
Обе функции не будут вызывать Windows API, но будутсравнивайте символы один за другим с учетом регистра.
Так что я советую вам просто не использовать указатель в вашем коде, а полагаться на простые string = UnicodeString переменные везде в вашем коде,и вместо этого используйте эту функцию:
function CompareStr(const S1, S2: string): Integer;
Сравнение будет таким же, и скрытого преобразования не будет.Проблема с WideChar вместо AnsiChar (т. Е. С наличием в два раза больше памяти) ничто по сравнению с преобразованием (два вызова WinAPI) между юникодом и текущей страницей ANSI.Чтобы процитировать ваш заголовок, направление конверсии не имеет значения: оно всегда намного медленнее, чем без конвертации.
Если вы ищете скорость, я подозреваю, что Mask.EditText определенно является узким местом в вашем коде.Этот метод отправит сообщение GDI, дождется ответа компонента, а затем повлияет на текст string.Вам лучше использовать временную переменную в стеке, если, как я подозреваю, вы используете это Mask.EditText выражение в цикле.