Ошибки PascalABC.NET

Объявлять их в implementation-части модуля. Если хочется еще вложенности, то в класс.

Когда-то давно висела в TODO реализация import. Это когда в корневой модуль можно импортировать имена из других модулей, чтобы избежать монструозных uses-ов в конечных программах, а подключать только корневой модуль.

Нет, речь шла о том, чтобы в пределах единого модуля прятать внутреннюю кухню. Если у меня библиотека и в ней есть тип Point, обозначающий в одной задаче точку с координатами (x,y), в другой - тоже точку, но уже с координатами (х1,х2,… xn,y), а в третьей - снова точку, но уже в полярной системе координат (rho,phi), а в четвертой точку с комплексными координатами, почему я должен вводить имена Point1, Point2, Point3 и т.д. и как объяснить пользователю, что в задаче аппроксимации функции одной переменной надо использовать массив точек типа Point2, а при поиске минимума функции трех переменных ответ будет в массиве переменных типа Point3 ? Сослаться, как когда-то Жванецкий писал, на “потому что ГОСТ у нас дурачок”?

­-Папа, а как называется конь-папа? -Жеребец -А конь-мама? -Кобыла -А конь-детка? -Жеребенок -А тогда какой конь называется просто конь?

Справка → Справочник по языку → Структура программы → Идентификаторы и ключевые слова: в списке ключевых слов присутствует слово “using”, которое ключевым словом не является.

У нас не воспроизводится.

А меня эта ошибка уже больше года мучает. Опытным путём установлено, она чаще всего (если не всегда) возникает, если поставить точку, и до того ни разу не использовать InelliSense. Причём, её иногда можно случайно поставить в любом месте, и возникнет ошибка.

Сигнатура проблемы: Имя события проблемы: CLR20r3 Сигнатура проблемы 01: PascalABCNET.exe Сигнатура проблемы 02: 3.2.0.1504 Сигнатура проблемы 03: 59614d8f Сигнатура проблемы 04: CodeCompletion Сигнатура проблемы 05: 1.0.0.0 Сигнатура проблемы 06: 59614d87 Сигнатура проблемы 07: 3f7 Сигнатура проблемы 08: 1d Сигнатура проблемы 09: System.StackOverflowException Версия ОС: 6.1.7601.2.1.0.256.1 Код языка: 1049 Дополнительные сведения 1: c029 Дополнительные сведения 2: c029c0f11049a032ed56fbfbf15c3309 Дополнительные сведения 3: cc84 Дополнительные сведения 4: cc84e7863767c39ca621ac072d78fe7f

3 сообщения перенесены в новую тему: Оффтоп: А у вас продаётся славянский шкаф?

Обнаружилась очень неприятная ошибка. Очень - потому что 1) она “плавающая”, т.е. я пока не могу четко локализовать условия, в которых она проявляется. 2) она относится к написанию методов класса где нельзя использовать ключевое слово forward и утверждается, что оно “не нужно”.

Имеется и редактируется код модуля, содержащего около десятка классов. К примеру, я редактирую код в классе X. При попытке компиляции совершенно неожиданно возникает сообщение об ошибке в классе Y о том, что невозможно найти тот или иной метод. Понятно, что у меня в коде каждого класса идет сначала конструктор, затем процедуры и функции, реализующие методы класса. Если из конструктора вызывается какой-то метод, то ВРЕМЕНАМИ возникает сообщение, что метод не найден. Если код метода поместить текстуально выше конструктора, ошибки не возникает. Я пока не привожу код модуля, потому что, повторюсь, еще не понял, какие действия вызывают сообщение об ошибке. Дело в том, что ошибка может пропасть сама собой, даже если оставить код конструктора первым… просто через время. И да, если кто-то захочет повторить эксперимент, у меня в описании конструктора имя Create отсутствует.

Вы реализуете методы сразу или позже, в разделе implementation

что такое forward для методов? они все по умолчанию “forward”

Методы пока сразу, я интерфейсы буду делать потом сразу на все.

Вот и я о том, что они все по умолчанию “forward”, а временами вдруг перестает компилироваться и не идет, пока не расставишь в порядке, чтобы сначала описать, потом вызвать.

Ну, ловите ошибку. Хотя бы вероятностно. Если мы ее тоже поймаем, то исправим.

Вот два файла. StudLib.pas (28,3 КБ) Этот нормально компилируется (PascalABC.NET 3.2, сборка 1506 от 21.07.2017) StudLib2.pas (28,3 КБ) А в этом возникает ошибка, причем с совершенно несуразным сообщением: “StudLib2.pas(94) : У операции преобразования типов допустим только один параметр.”

Отличаются файлы лишь местоположением конструктора в классе Decomp.

Вижу. Круто.

Крутизна в том, что этот файл “с ошибкой” может ни с того, ни с сего начать нормально компилироваться, если поиграться с методами совершенно в другом классе… А потом, если еще поиграться, опять перестаёт…

И еще. В классе Decomp есть одноименный метод. Если сменить его имя, например на Decomp1 и прописать в конструкторе вызов Decomp1, сообщение об ошибке изменится на более внятное - похоже, что компилятор “хочет forward”.

Вот:

1 лайк

Да. Особенно фотка хороша: "О, есть повод порадоваться! " )))))

Исправили.

1 лайк

Однако странное действие оказывает разделитель на вид вывода в .Println

// PascalABC.NET 3.2, сборка 1509 от 27.07.2017

begin
  var a:=Arr(-6.90052671328672,-3.57918606060606,-1.93019855477855,
      -0.841356503496501,0.0803939393939364,0.905317389277387,
      1.63663384615385,2.32564331002331,3.04623039627039,3.72874895104895);
  a.Println; Writeln;
  a.Println(',')
end.

похоже считается что 0.841356503496501,0.0803939393939364,0.905317389277387,1.63663384615385,2.32564331002331,3.04623039627039,3.72874895104895 это целое слово а - это не минус а тере, оно пытается перенести всё слово чтоб оно писалось на 1 строчке так что всё правильно

ну то есть нет, , должно быть разделителем как и пробел или тере, но по крайней мере это не случайное разделение, и при копировании, например, в блокнот - не должно быть переноса строки

var a := new byte[3](0,1,2);
var b := a[1:2];

у b не отображается тип, не работает автодоввод(Ctrl+Space) и т.п. ошибки вытекающие из этого которые решаться если анализатор кода поймёт что же всё таки такое это b

Все, что выводится на экран по Write/Print - это строка и никаких “переносов” там быть не может, не фантазируйте, из первого варианта вывода видно, что значение отрицательное. На самом деле это результат непродуманной (или ошибочной) компоновки на экране.