Замечания и предложения

Вряд ли. Для .Net, в котором программу на .Net можно быстро и просто собрать и запустить средствами .Net из другой программы, которая опять же, на .Net - существующего функционала, с небольшими дороботками, должно хватить. То есть, я имею в виду, можно собрать и запустить отдельно константные методы, до того как генерировать IL код для всего остального.

С другой стороны, мне кажется этот функционал легче, и что важнее - правильнее, было бы реализовать в качестве функционала IDE (не того огрызка что сейчас, а нормальной IDE). Ну а пока что - я бы лично реализовывал (да и не бы, вот пример) в качестве ещё 1 программы - упаковщика.

В отличии от призрачной возможности, что кому то будет не лень сделать нормальную IDE - собрать простенький упаковщик своего проекта, собирающий константные значения (как у меня - версия) и правильно добавляющий все компоненты (иконки .exe, манифест и т.п.) - не так уж и сложно.

Хотя, пример, наверное, не лучший, ибо константа версии у меня костыль)). Но, что я считаю там правильным - так это использование $include чтоб вставить значение константы, которую перед компиляцией сгенерирует упаковщик.

А чтоб работало всё как const функции - надо лишь ещё 1 .pas файл, который будет содержать эти все const функции. Упаковщик их компилирует и запускает, чтоб получить значения. И далее заменяет $include значения на то, что дал файл с const функциями.

Т.е. PascalABC.NЕТ уже без IDE рассматриваться не должен? Консольные там компиляторы, - они идут лесом?

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

Есть хорошая поговорка: “Гора родила мышь”. Вам не кажется, что в данном случае она может быть уместной? А вот от полноценного прекомпилятора/препроцессора я бы не отказался. Хоть это тоже не часто нужно, а учебному процессу не нужно вообще.

P.S. Ностальгически вспоминается интерпретатор REXX в СВМ на ЕС-ках. Мощный и удобный самостоятельный язык, который мог быть и препроцессором для PL/1. Rexx оказался настолько хорош,что жив и сейчас в OpenSource виде. Язык доступен для платформ AIX, Linux, Mac OSX, Solaris, Windows

1 симпатия

Проще не морочить голову компилятору, а запустить программу, узнать значение функции и подставить в константу.

НЕ ИЩИТЕ В ПРОГРАММИРОВАНИЕ ЛЁГКИХ ПУТЕЙ! Программист Моисей

1 симпатия

Товарищи, приведенный тут пример из С++ вообще не из реалий .NET. Зачем оно в нем нужно - иметь возможность объявлять всякие массивы на стеке с вычисляемым количеством значений(int Arr[N]), генерить шаблоны с переменными-аргументами, значения которых должны быть известны на этапе компиляции (template <int N>)… Таких проблем в Паскалях нет, и делать костыли для их решения абсолютно бессмысленно.

Кстати, вроде ж когда-то кто-то писал в качестве дипломной, или еще какой работы, плагин для Eclipse? Мертв?

Простите, генерация магических чисел в коде - вообще не лучший паттерн. Совсем.

Все плагины для Эклипса пишутся в расчёте на конкретную версию Эклипса и с другими не работают. По крайней мере, с другими я не талкивался. Тот плагин благополучно 4 года назад работал с какой-то версией Эклипса.

Собственно, нет проблем. Если кто-то хочет взяться - можно внедрить консольный компилятор в Visual Studio Code - говорят, очень хороший редактор.

Так и не надо!

@Admin как насчёт выложить презентации с pascalabc.net на гитхаб? Там тонна ошибок, в основном опечаток и остальной мелочи, вроде того что в последовательностях Range('a','z').Println ставит пробелы между буквами, хотя если запустить в паскале - выводит без пробелов.

Сколько бы там нибыло ошибок - там всё объясняется всё же лучше, чем смог бы я, поэтому я обычно на эти презентации посылаю новичков с куберфорума. Но, всё же, не хорошо, что там так много моментов которые запутывают.

Я когда то пробовал писать сюда что именно не так, но ничего из этого не вышло. Пулл реквестами исправлять было бы проще, и за того сколько там ошибок.

1 симпатия

Сделал новую тему:

В каком формате выкладывать и как Вы планируете править?

А не хотите на Киберфоруме сделать ссылки на раздел книги на нашем сайте?

Где? Я в закреплённые темы не писал, и, это скорее ваша работа, как разработчиков.

А на презентации я даю ссыль в каждой конкретной ситуации отдельно.

Ясно. Ну, киберфорум - не наша вотчина

Как насчёт добавить перегрузки операторов += и -= для System.IntPtr? В C# они автоматически выводятся из + и -, а вы вроде для всего стандартного, даже такого как BigInteger эти перегрузки в PABCSystem делали.

Опять пытаемся сползти к арифметике указателей? Очередной круг? Было бы неплохо прочитать тут, кому, в каких случаях и как часто это может быть нужно.

Арифметику указателей уже согласились сделать и issue уже висит.

Тут другое, это стандартный тип, при чём, совместимый с object и используемый чаще указателей.

Это не ответ. Например, если указатели используются в 0.01% программ, то 0.02% - это вдвое (!) чаще, но все равно лишь два случая на десять тысяч.

А на что вы собираетесь делать указатели? Если на массивы, для чего в первую очередь предназначена арифметика указателей, то в PascalABC.NET это сделать просто не получится. Если для чего-то специфического, то это незачем встраивать в язык - сделайте перегрузку += самостоятельно и пользуйтесь.

Итак, для чего?

Самый простой пример - Bitmap.LockBits. И так же это работает с любым другим буфером в графике.

Да и если массив - в GCHandle ничего сложного нет. Хотя тут полезность спорная, конечно.

Ну и, далее эти IntPtr нужны в чём то вроде System.Buffer.MemoryCopy.