Мнимые ошибки PascalABC.NET

Потому что .Net . Так же и геттеры/сеттеры свойств генерируются. В C# сам язык накладывает заплатки, чтобы этим методы небыли видны, хотя в рефлекции они всё равно мешаются.

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

@Admin с этим можно что-то сделать?

Да нет, тут точно какая-то ерунда. Если руками написать перегрузку оператора сравнения, то никакого op_Equality видно не будет.

Более того, если её не написать, то программа на c#, которая сравнивает эти записи просто не скомпилируется

1 лайк

Не понимаю вообще ничего этого. Вы говорите про то, какой IL код генерируется и что вас названия не устраивают. Мы эти претензии не принимаем. Можно и так. То что в наших записях их можно сравнивать на равно, а в C# - нет - это так.

Межъязыковое взаимодействие - это задача, решаемая нами во вторую очередь. Это оператор сравнения, который нужен именно для паскалевских record - никто не предполагает, что он будет в C# использоваться

Если я тут не отвечаю, то считаю это незначимым

@Admin то есть это действительно пара магических методов, которые идентифицируются как операторы сравнения только компилятором pabc. Я не согласен, что код для dll должен генерироваться по таким правилам. Сборка начинает вести себя неоднородно. А для пользователя другого .net языка это будут просто “методы со странными названиями”. Хотя и для пользователей pabc они так выглядят, ибо почему-то не скрываются. Хотя даже если и будут скрываться, то не совсем правильно это отдавать на откуп ide.

При этом выигрыш довольно сомнителен. Что бы record в либе выглядел нормально, придётся всё равно написать перегрузки самому. Тогда какая польза от автогенерации?

Ну окей, тогда надо в справке указать на магическую природу этих операторов, что бы хотя бы не натыкаться

тут люди всё-таки не просто так пишут. хотят разобраться без создания issue, если это просто “что-то очень похожее на баг”. тем не менее, ответ получить необходимо, ибо это нужно для дальнейшей работы. так что, думаю, игнорировать – не лучшее решение

2 лайка

А как насчёт implicit/explicit? Они тоже по сути магические и не видны из других .net языков :thinking:

Это не баг - в Паскале записи можно сравнивать на =. Здесь нам приходится поступиться связью с C#

я уже и не говорю, что это баг. я говорю, что правило генерации мне кажется не слишком логичным/удобным. ну получат шарповцы структурки сравниваемые. кому хуже станет?

а вот с implicit /explicit уже другой вопрос

@samurai я с вами согласен, но вы зря распинаетесь, @Admin снова ищет поводы не тратить время, потому что не критично.

Может попробуете сами это подправить? Должно быть относительно не сложно, даже без знания кишок компилятора.
По крайней мере относительно всяких #2736, где куча крайних случаев всё ломает…

Я, по крайней мере, подробное ревью пула постараюсь вам сделать.
Но скрывать не буду - меня эта тема тоже за 5 точку не кусает.

Да я бы с радостью, но боюсь даже на поиск соответствующего участка в коде уйдёт слишком много времени. Я с устройством компилятора совсем не знаком. С# на уровне чтения и написания кода по доке. Да и в VS не работал. В общем, не слишком подходящий наборчик для такой идеи :smile:

1 лайк

Подскажите пожалуйста в чём может быть ошибка и как исправить? Строка 1:" Путь к сборке имеет недопустимые символы"

{$reference 'sfmlnet-graphics-2.dll'}
{$reference 'sfmlnet-system-2.dll'}
{$reference 'sfmlnet-window-2.dll'}

{$apptype windows}

uses System; 
uses SFML.Graphics;
uses SFML.Window;
uses SFML.System;

Слишком мало информации.

  1. Версия последняя?
  2. Может это связано с названием папки, в которой лежит программа и все .dll файлы? Какие-то особые знаки там? Попробуйте какой то минимальный тест, к примеру в корне диска C это компилировать.
  3. Приложите архив в котором компиляция программы на паскале даёт эту ошибку.

Помог перезапуск и эта инструкция в архиве с программами:

Компилятор PascalABCNET выдаёт ошибки при компиляции новых программ. Поэтому перед началом работы загрузите файл SFML shader.pas и запустите его. Затем загружайте свои программы с диска или пишите новые.

Откуда это вообще? Ни разу не слышал про эти “ошибки при компиляции новых программ”.
Но если это и правда так работает - такое поведение требует исправления, а не каких то костыльных обходов.

Ага, кажется нашёл… Вот книга и тот самый архив. По хорошему, эти ссылки должны были приложить вы, для контекста.

Но, тем не менее, у меня ошибка не воспроизводится. Беру рандомную программу из архива и запускаю - всё работает, без дополнительных танцев с бубном (или со всякими SFML shader.pas).

Какую конкретно программу из архива вы запускали получая эту ошибку?

У меня такое на проге “Шейдер 5” всегда возникает;)