Задачка для спинного мозга - 2.

[min@y™]

Коллеги, я щас портирую TECXMLParser под unicode-версии компиляторов. Застопился на одном методе, никак не могу вкурить, что он делает.
Кому интересно, посмотрите.

procedure TXMLTokenizer.ReadBuffer;
var
  Count: Integer;
begin
  Inc(FOrigin, FSourcePtr - FBuffer);
  FSourceEnd[0] := FSaveChar;

  Count := FBufPtr - FSourcePtr;  

  if Count <> 0
    then Move(FSourcePtr[0], FBuffer[0], Count);

  FBufPtr := FBuffer + Count;
  Inc(FBufPtr, FStream.Read(FBufPtr[0], SizeOf(Char) * (FBufEnd - FBufPtr)));
  FSourcePtr := FBuffer;
  FSourceEnd := FBufPtr;

  if FSourceEnd = FBufEnd
    then begin
           FSourceEnd := LineStart(FBuffer, FSourceEnd - 1);
           if FSourceEnd = FBuffer
             then Error(SLineTooLong);
         end;

  FSaveChar := FSourceEnd[0];
  FSourceEnd[0] := #0;
end;

Вот там класс:

type
  TXMLTokenizer = class(TObject)
  private
    FStream: TStream;
    FOrigin: Longint;
    FBuffer: PChar;
    FBufPtr: PChar;
    FBufEnd: PChar;
    FSourcePtr: PChar;
    FSourceEnd: PChar;
    FTokenPtr: PChar;
    FStringPtr: PChar;
    FSourceLine: Integer;
    FSaveChar: Char;
    FToken: Char;
    procedure ReadBuffer;
    procedure SkipBlanks;
  public
    constructor Create(Stream: TStream); virtual;
    destructor Destroy; override;
    procedure CheckToken(T: Char);
    procedure CheckTokenSymbol(const S: string);
    procedure Error(const Ident: string);
    procedure ErrorFmt(const Ident: string; const Args: array of const);
    procedure ErrorStr(const Message: string);
    procedure HexToBinary(Stream: TStream);
    function NextToken: Char;
    function SourcePos: Longint;
    function TokenComponentIdent: string;
    function TokenFloat: Extended;
    function TokenInt: Longint;
    function TokenString: string;
    function TokenSymbolIs(const S: string): Boolean;
    property SourceLine: Integer read FSourceLine;
    property Token: Char read FToken;
  end;

Если чо, оригиналы на торри.нет. Могу дать ссылку.

[Utkin]

Перемещает данные из одной области памяти в другую на основании длины и еще каких-то расчетов. Для Вас ключевое место:

Inc(FBufPtr, FStream.Read(FBufPtr[0], SizeOf(Char) * (FBufEnd - FBufPtr)));

Так как он там вычисляет длины как раз с учетом Char, а для юникода может быть критично, что там 1, 2 или 4 байта. Ну и там может смещения (типа FSourceEnd - 1) надо проверять будет.
Мне другое интересно - зачем вообще это понадобилося?
Может вот он Вас чем обидел?
Так как:

Full unicode support even for D5-D2007.

А также всяческие Лазарусы и прочие фрипаскали.
И вообще:

OXml supports all Delphi versions starting from Delphi 5 on all platforms: Win32, Win64, OSX, iOS, Android. Currently I tested: Delphi 7, 2007, 2009, 2010, XE, XE2, XE3, XE4, XE5, XE6, XE7, XE8. Delphi 5, 6, 2005 and 2006 are supported as well.
Corresponding C++Builder compilers should be supported, too (untested yet).
OXml supports Lazarus 1.0 and newer on all platforms (tested Win32, Win64, Linux, MacOSX).

[min@y™]

ключевое место

сорь, это моя правка. в оригинале только ansi - без sizeof(char).

Может вот он Вас чем обидел?

очень громоздкий. я пробовал выковырнуть только нужное (загрузку и сохранения), однако мелочи тянут за собой ещё код, а он - ещё и т.д. В итоге как было километровое полотенце кода, так и осталось.
ECXML - это у меня 1 короткий модуль (uXmlParser.pas); было 2, но я их в один слил. Меня всё устраивает, кроме отсутствие utf8 и unicode-строк. Сохранение я сделал легко, там всё понятно: перевести string в utf8 и сохранить - не проблема.
а вот загрузка - никак, не понимаю я, что тут делается.

[Человек_Борща]

у IDE давно свои библиотеки обработки XML есть, зачем грабли - не понятно.

[Utkin]

Меня вообще настораживают такие парсеры. XML он как бы давно с поддержкой юникода, если не с самого рождения иначе какой же это XML а стало быть какой же это парсер. Как бы еще фатальных недостатков потом не всплыло.

[min@y™]

у IDE давно свои библиотеки обработки XML есть, зачем грабли - не понятно.

чо тут непонятного? Привык, лет 8 юзаю этот парсер, куча кода под него заточена.
И переделывать, ипстественно, неахота - 100500 тонн времени уйдёт, в том числе и на изучение стандатных XML-примочек.
Не спорю. Но на это есть отладчик.

[Человек_Борща]

но все же посмотрите Perfomance здесь. Переходить на новое это всегда проблема, больно, плохо и вообще ад. Одно хорошо, все это длится не так долго как думается, а переход происходит быстрее чем можно себе представить/ ECXMLParser решает любые не существующие в NEWPARSER, проблемы.

Если совсем плохо:
Пишите класс TECXMLParser а внутри него создаете современный парсер используя тот же OXml. И во всех проектах всем свежо и прекрасно.

Это пост агитации отказываться от старого и не боятся нового, не кусается.

[Utkin]

чо тут непонятного? Привык, лет 8 юзаю этот парсер, куча кода под него заточена.

Вот так и приходит старость

[Smitt&Wesson]

Сообщение от Utkin

Вот так и приходит старость

Чё, тоже стареешь?