В 1660 билде всё должно работать. Попробуйте установить его в другой каталог: возможно, при инсталляции поверх некорректной версии что-то пошло не так
Ошибка с кликом проявлялась только в “старом” билде 1660, в “новом” же 1660 – все нормально (установил поверх старого). Я не понял, поскольку номер билда не изменился – это была какая-то проблема с компиляцией проекта в VS или что-то поправили в самом коде?
PS. Кстати, в “старом” 1660 та же ошибка еще появлялась у меня при любой попытке вставить текст из буфера, сейчас все ОК.
Ну, ОК и ОК. Путаница с номером билда - это мы откатывались по репозитарию, потом восстанавливались - видимо, из-за этого.
Это компилируется нормально:
type
t1 = class
constructor create(a,b: byte) := exit;
end;
t2 = class(t1)
constructor create(s: string) :=
create(0,0);
end;
begin end.
А это нет:
type
MyException=class(Exception)
constructor :=
create('Some text');//Ошибка: Неверное количество параметров функции
end;
begin end.
Но если добавить inherited
- оно тоже компилируется:
type
MyException=class(Exception)
constructor :=
inherited create('Some text');
end;
begin end.
Внимание вопрос, почему только второй случай требует inherited
? Это ошибка?
И ещё 1:
Это компилируется:
begin
var s := $'\{ {#65} \}';
writeln(s);
end.
Но при запуске выдаёт ошибку:
Ошибка времени выполнения: Входная строка имела неверный формат.
Я декомпилировал и получил это:
PABCSystem.PABCSystem.Writeln(
(object) string.Format("\\{0} \\}", (object) 'A')
);
Вместо:
PABCSystem.PABCSystem.Writeln(
(object) string.Format("\{ {0} \}", (object) 'A')
);
Сама идея была в том чтоб получить строку типа { A }
. Что с этим делать, и добавлять ли в issue?
Мне кажется, да. В PABC конструкторы из предков должны быть доступны сразу
Вообще что-то странное здесь написано. В строках $ не работают {
Ну смотрите, вот простейший пример с System.Drawing.Point
:
{$reference System.Drawing.dll}
uses System.Drawing;
begin
writeln(new Point(0,0));
end.
Это выводит {X=0,Y=0}
. Мне тоже нужен был тип с 2 координатами + своими плюшками. Я решил сделать функцию для вывода:
function ToString: string; override := $'\{X={X},Y={Y}\}';
Но не тут то было. Из за того что бекслеши как то ломаются - это не работает. Во всяком случае то во что их превращает - явно неадекватно.
Ну да, пишите в Issue. Надо чем-то заменить { и } при выводе в интерполированных строках. В C# это кстати {{ и }}
А бекслеш ввести вообще никак? Тогда б и writeln(' \' ')
, и т.п. работало бы… Я конечно не так много в жизни видел, но всё на чём программировал, кроме паскаля (С языки и обе джавы), поддерживали его. С#, похоже (проверил), таки, понимает только {{
и }}
, но не \{
и \}
, но что мешает оба способа добавить?)) Это не то что может добавлять невнятные ошибки или что то типо того.
Вообще, я считаю, что с добавлением форматной строки - появилась сильная нужда в Escape-последовательностях. К примеру, когда хочешь чтоб в обычной строке был символ '
- можно просто вставить в середину строки '+#39+'
. Конечно криво, но сойдёт. Но с форматной строкой такое не прокатит, весь смысл то в ней, в том чтоб ничего не разрывать.
P.S. возможно стоит отдельно вынести это?
Надо делать как в C#
Зачем?
Для совместимости, потому что это языки одной линейки.
Если на это ориентироваться - надо и функции без скобочек запретить (пожалуйста не надо). Это мелкие отличия, вполне допустимые, которые просто делают приятно. И главное при переводе с C# на паскаль оно ведь будет работать, как и со скобочками. И с паскаля на C# тоже, если не использовать синтаксический сахар (как и должно быть, ведь C# это чистый .Net, а паскаль с примочками).
Надо экранировать {{ В паскале слеши не используются для экранирования. Зачем мешанину разводить.
Мешанины не будет если не использовать их, зато с ними можно будет делать и другое. Ну допустим {
и }
теперь можно, но, к примеру, '
всё ещё нельзя. Его заменять на ''
или что то типо того - это как раз разводит мешанину. Лучше всё же одинаково, бекслешем.
Почему нельзя - также ‘’
Но в C# то \"
а не ""
)))
Ошибка описания в методах расширения для array и для list (в справке тоже) function LastIndexMax ///возвращает индекс последнего минимального элемента.
Ну, ошибка конечно не самая критичная, но пусть будет…