Это - неприятная ошибка, связанная скорее всего с маломощностью используемого LR-парсера. Атрибуты могут быть и перед типами и перед подпрограммами. Пирсер воспринимает, что секция типов еще не закрылась, и считает, что после атрибута должно быть описание типа.
Устранить ее человеческим образом, похоже, не удастся. То есть, получается. что сразу после секции типов нельзя использовать процедуру с атрибутами.
Похоже Real.Parse(…, System.Globalization.NumberStyles.AllowDecimalPoint) не работает
Программа не хотела парсить число пи, пока я не написал этого монстра:
begin
var realLine := '3.1415926';
var pi := 0.0;
try
Real.TryParse(realLine, System.Globalization.NumberStyles.AllowDecimalPoint,
new System.Globalization.NumberFormatInfo(), pi);
except
end;
Writeln(pi);
end.
Сегодня создал массив из 32 000 элементов. В режиме debug решил просмотреть значения первой десятки. Когда навел мышь и нажал “+” рядом с именем переменной, то программа повисла. Считаю, что это ошибка, и прошу исправить. Возможно, загружать такой большой массив в память это неправильно, но виснуть при этом ide не должна.
Как ни странно, но в простых программах у меня все тоже работает. Но если структура более сложная, то переименовывание происходит не полностью, или вовсе не происходит.
type CharOccurances = record
c: Char;
n: Integer;
end;
begin
var charData := new CharOccurances[24];
for var i := 0 to 23 do
charData[i].c := chr(ord('a') + i);
foreach var data: CharOccurances in charData do
foreach var symboll: Char in 'hello, world!' do
if symboll = data.c then
data.n += 1;
for var i := 0 to 23 do
Writeln(charData[i].c, ' ', charData[i].n);
end.
Ошибка времени выполнения: System.BadImageFormatException: Была сделана попытка загрузить программу, имеющую неверный формат. (Исключение из HRESULT: 0x8007000B)
Стек:
в Program1.Program.$Main()
в Program1.Program.Main()
begin
var realLine := '3.1415926';
var pi := 0.0;
try
Real.TryParse(realLine, System.Globalization.NumberStyles.AllowDecimalPoint, pi);
except
end;
Writeln(pi); // выведет 0
end.
ну здесь скорее не TryParse, а Parse. В этот метод надо передавать NumberFormatInfo с заданным NumberGroupSeparator. Короче проще использовать StrToFloat.
Функция “сгенерировать реализацию” работает не совсем корректно. Если генерируется реализация для подпрограммы с параметрами по-умолчанию, то параметры по-умолчанию будут указаны и в реализации подпрограммы, что синтаксически неверно.
Помимо этого, имеется одна странность в её работе. Иногда, если есть несколько нереализованных подпрограмм, то она генерирует реализацию сразу для всех таких подпрограмм, а иногда только для той, над которой было вызвано контекстное меню.
И ещё хочется, что бы место для кода реализации было выбрано в соответствии с порядком объявления подпрограмм. То есть, что бы порядок реализации подпрограмм повторял порядок их объявления.
Почитал тему про алгоритм ханойских башен, вдохновился, хотел реализовать графически. на скорую руку написал код, прикрепляю его во вложении ниже. при компиляции открывается окошко внутренней ошибки компилятора с текстом: Указанный метод не поддерживается.