1 Тема от 0CodErr

  • 0CodErr
  • Заинтересованный
  • Неактивен
  • Зарегистрирован: 08.06.2019
  • Сообщений: 264

Тема: Спор о типах

Freeman пишет:

KolibriChar остается. Сторонний код или должен быть уже портирован под современные версии Delphi самими разработчиками, или будет компилироваться без изменений в тех версиях Delphi, для которых он предназначен. Код для KolibriOS должен писаться с использованием KolibriChar, ради совместимости со всеми версиями Delphi у потенциальных пользователей SDK.

Попробую ещё один раз объяснить, иначе как ты сам говоришь "медицина бессильна" smile

Если не объявить в ОДНОМ месте в модуле KolibriOS

type
  Char = AnsiChar;

то тогда придётся объявлять так ВЕЗДЕ, где есть сторонний код, который портирован, который работает с новыми версиями и т.д. и т.п.

пример привёл уже, ты снова похоже не читал

program TestChar;

{$APPTYPE CONSOLE}

type
  Char = AnsiChar; <<--- вот это придётся делать для KolibriOS

var
  C: Char;
  Arr: array[Char] of Char;

begin
  for C := Low(Arr) to High(Arr) do
  begin
    Write(ord(C), #10);
  end;
  ReadLn;
end.

а можно так 

type
  Char = AnsiChar; <<--- вот это придётся делать для KolibriOS

не делать в КАЖДОМ проекте, а сделать только в модуле KolibriOS и тип Char переопределится автоматически при подключении модуля KolibriOS, CRT тоже использует этот модуль.

smile может ещё скажешь, надо KolibriString выдумать smile

В общем, если и когда вдруг появится у меня время, то я буду делать по-нормальному.
У меня будет самый обыкновенный Char, Dword и Qword.

Насчёт знаковых типов, возможно, по аналогии с MASM, с префиксом Signed.
То есть будет так:

   знаковые: SByte, SWord, SDword, SQword
беззнаковые:  Byte,  Word,  Dword,  Qword

должно быть логично и не должно возникать неоднозначностей.

Например, как в

Go

 int8,  int16,  int32,  int64
uint8, uint16, uint32, uint64

float32, float64

Rust

 i8, i16, i32, i64
 u8, u16, u32, u64
 
 f32, f64

C

 int8_t,  int16_t,  int32_t,  int64_t
uint8_t, uint16_t, uint32_t, uint64_t 

float, double

2 Ответ от 0CodErr (изменено: Freeman, 20.06.2020 в 19:03)

  • 0CodErr
  • Заинтересованный
  • Неактивен
  • Зарегистрирован: 08.06.2019
  • Сообщений: 264

Re: Спор о типах

Но вообще хорошо бы иметь хоть какой-то roadmap.
Иначе не ясно, куда мы движемся, а куда точно нет.
Если изначально был план программировать на Delphi, используя KolibriOS API — то этот план уже и так реализован вполне.
Если же речь о поддержке ещё чего-то более или менее стандартного, то тогда оно и должно быть стандартным, а не отсебятиной.
Возможно, стоило бы создать какие-то проекты\утилиты под KolbriOS на Delphi, и подгонять\тестировать RTL уже с этими проектами.

3 Ответ от Freeman

  • Freeman
  • Freeman
  • Администратор
  • Неактивен
  • Зарегистрирован: 08.06.2015
  • Сообщений: 602

Re: Спор о типах

0CodErr пишет:

Но вообще хорошо бы иметь хоть какой-то roadmap.

Ты с ним сразу не согласишься и уйдешь.

Добавлено 2020-06-20 в 21:04

0CodErr пишет:

Если не объявить в ОДНОМ месте в модуле KolibriOS

type
  Char = AnsiChar;

Похоже, я придумал пример, показывающий, что это работать не будет. Раз типы не описаны в System, они прошиты в компилятор. Тогда символьные и строковые константы он тоже генерит в соответствии со своим представлением. В Delphi 2010+ должно быть так:

var
  A: Char = 'ж'; // 36 04
  B: PChar = 'Колибри'; // 1A 04 3E 04 3B 04 38 04 31 04 40 04 38 04 00 00

  C: AnsiChar = 'ж'; // E6 на русской Windows, заругается на небезопасную константу
  D: PAnsiChar = 'Колибри'; // CA EE EB E8 E1 F0 E8 00 на русской Windows, тоже заругается

Пока не проверял.

4 Ответ от 0CodErr

  • 0CodErr
  • Заинтересованный
  • Неактивен
  • Зарегистрирован: 08.06.2019
  • Сообщений: 264

Re: Спор о типах

Freeman пишет:

Раз типы не описаны в System, они прошиты в компилятор.

Ну вообще если открыть System.dcu, то они там будут эти типы, и если знать внутреннее устройство .dcu, то можно вручную подправить при желании.

Freeman пишет:

Тогда символьные и строковые константы он тоже генерит в соответствии со своим представлением.

Да, с этим явно может быть что-то не так.
Но в справке по String types написано

String types can be mixed in assignments and expressions; the compiler automatically performs required conversions. But strings passed by reference to a function or procedure (as var and out parameters) must be of the appropriate type. Strings can be explicitly cast to a different string type

вот такой код

program Test;

{$APPTYPE CONSOLE}

const
  CS1: AnsiString = 'mytext';
  CS2: WideString = 'mytext';

begin
  WriteLn(Length(CS1));
  WriteLn(Length(CS2));
  WriteLn(CS1);
  WriteLn(CS2);
  WriteLn(CS1 = 'mytext');
  WriteLn(CS2 = 'mytext');
  ReadLn;
end.

и результат 

6
6
mytext
mytext
TRUE
TRUE

вроде всё верно

For Unicode (WideString) strings, Length returns the number of bytes divided by two.

А ещё можно так

program Test;

{$APPTYPE CONSOLE}

begin
  WriteLn(AnsiString('mytext'));
  WriteLn(WideString('mytext'));
  ReadLn;
end.

результат

mytext
mytext

Добавлено 2020-06-21 в 00:36

Не думаю, что эта проблема не имеет решения.
Ведь имена секций, символов и т.д. во всяких PE, MSCOFF, OMF — явно не юникод, и с этим надо как-то работать, значит, решение должно быть.

5 Ответ от Freeman

  • Freeman
  • Freeman
  • Администратор
  • Неактивен
  • Зарегистрирован: 08.06.2015
  • Сообщений: 602

Re: Спор о типах

0CodErr пишет:

если знать внутреннее устройство .dcu, то можно вручную подправить при желании.

Не в проекте с открытыми исходниками. Да и не сработает. Строки-то уже сгенерены.

Все остальные примеры неэквивалентны современным версиям Delphi. Старый Delphi и старая справка. Ты никак не возьмешь в толк, что современных версиях добавлены новые юникодные строки и переписаны существующие AnsiString.

Немного истории. WideString — COM BSTR. Добавлены в Delphi 4 вместе с поддержкой интерфейсов. Распределение и финализация строки делаются через COM API. Не имеют счетчика ссылок, неэффективны в плане перераспределения памяти. За неимением лучшего их стали использовать для юникод-строк вообще, пока в Delphi 2010 Embarcadero не представила новый способ.

В новых версиях WideString остались для чего предназначались изначально — для COM. Для повседневного же использования были реализованы UnicodeString со счетчиком ссылок, а AnsiString обзавелись кодовой страницей. UnicodeString так же прошиты в компилятор и требуют своих библиотечных функций для работы. Всё это нам придется реализовать.

В старых версиях Delphi так:

type
  StrRec = packed record
    RefCount, Length: LongInt;
  end; 

var
  A: AnsiString = 'код';    // FF FF FF FF 03 00 00 00 EA EE E4 00

В юникодных версиях Delphi уже так:

type
  StrRec = packed record
    CodePage, ElemSize: Word;
    RefCount, Length: LongInt;
  end; 

var
  A: AnsiString = 'код';    // E3 04 01 00 FF FF FF FF 03 00 00 00 EA EE E4 00
  B: UnicodeString = 'код'; // B0 04 02 00 FF FF FF FF 03 00 00 00 3A 04 3E 04 34 04 00 00

Для Колибри однозначно нужны строки с кодовой страницей. Я хочу реализовать их так, чтобы работало во всех версиях Delphi с минимальными ограничениями. Нужно только время.

0CodErr пишет:

Ведь имена секций, символов и т.д. во всяких PE, MSCOFF, OMF — явно не юникод

Имя секции PE — UTF-8, согласно документации Microsoft. Недавно проверял. Если назвать секцию «код» по-русски, PE Tool ее верно отобразит. В 8 байт влезает только 4 русских символа, к сожалению.

В Delphi 2010+ поддержка встроена в компилятор:

type
  UTF8String = AnsiString(65001);
var
  A: UTF8String = 'код'; // E9 FD 01 00 FF FF FF FF 06 00 00 00 D0 BA D0 BE D0 B4 00

6 Ответ от 0CodErr (изменено: Freeman, 19.06.2023 в 20:31)

  • 0CodErr
  • Заинтересованный
  • Неактивен
  • Зарегистрирован: 08.06.2019
  • Сообщений: 264

Re: Спор о типах

Freeman  пишет:

Кроме того, я не уверен, что удастся корректно переопределить встроенный тип. В System он нигде не задан, встроен в компилятор.

Freeman  пишет:

Встроенные типы переопределять нельзя.

А не приведёт ли это к проблемам?
Вот мы используем в System типы AnsiChar, PAnsiChar, AnsiString вместо Char, PChar, string, но для компилятора-то это всё равно будут Char, PChar, string, независимо от того как мы сами написали(в модуле System это игнорируется).

Однако, FillChar заполняет только байты, даже если Char эквивалентен WideChar.

Например, как себя поведёт функция MkDir?

procedure MkDir(const S: string); overload;
procedure MkDir(P: PChar); overload;

Кто-нибудь тестировал поведение функций, когда Char = WideChar?

И я думаю, что в связи с этим нет смысла в System делать замену (Char, PChar, string) -> (AnsiChar, PAnsiChar, AnsiString ), ведь компилятор всё равно это проигнорирует, а программист будет введён в заблуждение(будет думать, что на самом деле AnsiChar жёстко задан).

Добавлено 2022-02-02 в 15:51

И в структурах, кстати, та же самая ситуация, например, в TTextRec, TFileRec используются Char.

7 Ответ от Freeman

  • Freeman
  • Freeman
  • Администратор
  • Неактивен
  • Зарегистрирован: 08.06.2015
  • Сообщений: 602

Re: Спор о типах

Тема о строковых типах исчерпала себя. Я как мог объяснил выше, больше сказать нечего. Тему закрываю.

Если по итогам реализации выяснится нечто новое — открою и отпишусь. Если строки реализую не я и обнаружится нечто новое — пишите в личку.