переопределение операторов Вход,Копия,Выход для записей

[kazalex]

qivi, не вижу проблемы в совместимости с дельфями (более того, считаю это плюсом FPC). О каких рамках речь, когда у FPC есть собственный диалект? Кто мешает развивать его без оглядки на делфи?

[wavebvg]

совместимость с делфи один из тормозов развития FPC+Lazarus

Ну... Не сказал бы... Обычно получаешь то, чего ждешь от компилятора, а если не получаешь - идёшь и читаешь документацию.
А если городить огород самостоятельно, то тут же нужно:
1. Подробный фич реквест и его обсуждение
2. Очень плотное тестирование фичи до реализации (т.е. что есть и какой результат ожидаем), набор автоматических тестов для недопущения регресса
3. Поддержка множества платформ (есть ли автоматическое тестирование компилятора FPC под все поддерживаемые платформы и архитектуры?)
4. Желание реализующего фичу человека выполнить пункты 1-3

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

Да, кстати, если реализовать в компиляторе учет области видимости объектов, то это сделает возможным реализацию тех же строк самостоятельно: компилятор сам вызовет у объекта метод инициализации и деинициализации (не "конструктор и деструктор", а спец. методы при вхождении/выходе из области видимости).

[Дож]

Да, кстати, если реализовать в компиляторе учет области видимости объектов, то это сделает возможным реализацию тех же строк самостоятельно: компилятор сам вызовет у объекта метод инициализации и деинициализации (не "конструктор и деструктор", а спец. методы при вхождении/выходе из области видимости).

Это на самом деле вообще Killer Feature, которая открывает новые возможности при разработке своих библиотек.

[kazalex]

компилятор сам вызовет у объекта метод инициализации и деинициализации (не "конструктор и деструктор", а спец. методы при вхождении/выходе из области видимости).

Никакие спец. методы при входе/выходе в/из область видимости не нужны. Нужны дефолтные конструктор с деструктором + оператор копирования, вызываемый как при явном, так и при неявном копировании. То есть, фактически, нужна замена для трех компиляторных magic functions: InitRecord, FinalizeRecord, CopyRecord (названия условны разумеется). Это позволит полностью контролировать время жизни кастомных типов.

Добавлено спустя 4 минуты 52 секунды:

Это на самом деле вообще Killer Feature, которая открывает новые возможности при разработке своих библиотек.

Дельфийцы за неё давно уже голосуют на QC, а что мешало сделать это FPC'шникам жалующимся на рамки?

[wavebvg]

Никакие спец. методы при входе/выходе в/из область видимости не нужны. Нужны дефолтные конструктор с деструктором + оператор копирования, вызываемый как при явном, так и при неявном копировании.

++-кий вариант тоже хорошо, но синтаксис придется немного менять...

[kazalex]

wavebvg, это просто вопрос терминологии. Я назвал их дефолтными конструктором и деструктором потому, что так официально называли эти фичи представители кодгира. В приводимом мной фичриквесте они обозначены как операторы класса, что, по моему, даже лучше.

[kazalex]

Кстати, вот из мейллиста (fpc-devel maillist):

Am 08.02.2015 22:08 schrieb "Maciej Izak" <hnb.code@gmail.com>:
> To achieve this I need to create new special record operators:
>
> ====== code begin ======
> {$MODESWITCH MANAGEMENTOPERATORS}
>
> TValue = record
> ...
> class operator Initialize(Data, TypeInfo: Pointer): pointer;
> class operator Finalize(Data, TypeInfo: Pointer): pointer;
> class operator Copy(Source, Dest, TypeInfo: Pointer): pointer;
> end;
> ====== code end ======
This is /really/ bad design. If you want such operators they would need to be defined like this:
TValue = record
...
class operator Initialize(var aRec: TValue);
class operator Finalize(var aRec: TValue);
class operator Copy(constref aSource: TValue; var aDest: TValue);
end;
====== code end ======
Regards,
Sven

[hinst]

опять желающие сделать из FreePascal ололо-C++ набигают! Кошмар! так нельзя! чем проще тем лучше! а если делать всякие такие фичи, всё только ещё усложнится! вон строки в 3.х уже испортили!

[Дож]

опять желающие сделать из FreePascal ололо-C++ набигают! Кошмар! так нельзя! чем проще тем лучше!

Эти операторы не являются тем, что делает С++ монструозным. Не все фичи С++ плохи.

[kazalex]

а если делать всякие такие фичи, всё только ещё усложнится! вон строки в 3.х уже испортили!

Как раз с такой фичей (перегрузкой операторов) паскаль становится нормальным языком, где кастомные типы являются first class citizens и не требуется compiler magic для реализации типов вроде strings, dynamic arrays, variants. И перекодируемые строки, кстати, тоже классная штука, зря её из дельфей выпилили.

[SSerge]

И перекодируемые строки, кстати, тоже классная штука, зря её из дельфей выпилили.

Это как выпилили? И когда?

[wavebvg]

опять желающие сделать из FreePascal ололо-C++ набигают!

Не в C++ дело - это и вправду нужная штука, просто для её реализации требуется сильно повредить своб психику:
1. Блок декларации выделен, знаит неопнятно, вызывать это дело сразу после входа в блок или ждать первого обращения.
2. Если переменная не используется - запроса на инициализациюю не будет
3. Нужно как-то передать параметры инициализации
4. При выходе из области видимости не всегда нужно всё поудалять
5. RTTI с данными идеями вообще уживаться будет очень плохо

Исходя из 4х пунктов становится понятно, что конструктор/деструктор - более универсальное понятие в данном контексте и лучше не извращаться.
В тоже время, с определённой долей извратности, можно получить рабочий вариант.

Кошмар! так нельзя! чем проще тем лучше!

Если вызывать Init()/Deinit() для записи при начале использования явно и переопределить оператор (уже есть), то нет никакой разницы! Но инициализацию всё-таки стоит иметь, хотя бы на уровне синтаксического сахара (чтобы не выставлять значения по умолчанию, когда они очевиды, но каждый раз приходится об это мзадумываться).

[kazalex]

Это как выпилили? И когда?

В NextGen компиляторе однобайтовых строк нет вообще. Пока он используется исключительно для мобильных приложений, но кто знает.

[Дож]

1. Блок декларации выделен, знаит неопнятно, вызывать это дело сразу после входа в блок или ждать первого обращения.

Конечно же, при входе в блок, а не при первом обращении.

3. Нужно как-то передать параметры инициализации

Не нужны параметры. Хочется параметров - используйте обычный конструктор.

4. При выходе из области видимости не всегда нужно всё поудалять

Оператор выхода из области видимости сам решит что удалять, а что - нет.

[hinst]

ну тогда давайте убедим разработчиков FPC сделать нам такую фичу! может быть, сделают)) только в 3.0 она уже не войдёт потому, что список фич для FPC 3.0 уже зафиксирован((

Добавлено спустя 2 минуты 41 секунду:
насколько я знаю они сейчас заняты
1. Всякими фичами для улучшенной совместимости с новейшими Delphi
1.1. Улучшенное RTTI
1.2 Двухбайтные строки
2. Доделыванием<шаблонов>
2. Доделыванием строк с динамической кодировкой и RTL для них