А зачем искать переменную, которая вводится в месте её использования? В длинном коде придётся крутить мыша, чтобы каждый раз посмотреть список переменных.
В одном хорошем фильме эту ситуацию разрешили так: не нужно делать глупости даже от скуки.
Чтобы не было скучно, возьмите книгу по современному программированию и учитесь уму-разуму.
Для начала, кодировку файлов, создаваемых IDE. Добавление BOM в любой сохраняемый файл, особенно, не содержащий ни единого символа вне ASCII — это глупо.
Далее, добавить различные операторы, которые есть в нормальном паскале, но которых нет в ABC. Не так уж их и много, readstr например.
Убрать предупреждения при использовании нормальных описаний переменных (до блока begin/end) и убедиться, что они локальны для блока, не смотря на то что их описание расположено вне его. Убрать предупреждения при использовании операторов вроде Program name; и прочего.
Убирать модуль school бессмысленно на данный момент. Если вам поступит пожелание от минобра, чтобы на сайте появилась версия без него, тогда будет о чём говорить.
С указателями можно просто привести синтаксис в соответствие с другими диалектами паскаля. Так-то указатели уже есть.
Предположим, в одной программе есть несколько циклов, везде счётчик - это переменная i типа integer, причём проходящаяся по одному и тому же диапазону (например массиву, прочитанному из файла). Зачем её описывать более одного раза?
А если потом понадобится поменять тип на int64, так как ширины не хватило, предлагаете копаться во всём коде и менять вместо одного исправления в секции var?
Вы уверены, что это действительно прямо таки “закон”, а не ваше личное стилистическое предпочтение?
Вы же знаете, что вам ответят и куда пошлют, да? Да точно знаете, уже посылали. Вы точно хотите повторять этот день сурка?
А в чём проблема? JIT компилятор выделит общую область памяти под них, потому что период жизни переменной одного цикла закончится до начала второго.
И если в разных циклах нужна переменная разных размеров - как раз лучше если изначально существует по 1 переменной на цикл, а уже автоматические системы решают как их объединять.
Более того, указывать тип переменной цикла обычно плохо. Его определяет автоматически по типу диапазона.
а кому оно мешает? ладно бы речь шла про web, где с php и js действительно есть какие-то проблемы. Тут это вроде жёвано-пережёвано. И по-моему, всё таки пришли к выводу, что если не пытаться организовать себе геморой, то он не возникнет.
как я понимаю, readstr это что-то вроде string.ReadInteger, string.ReadWord и тд. Чем эти аналоги не годятся мне не особо понятно. избыточность решений это конечно хорошо, но не вижу смысла уделять этому особое внимание. может быть есть какие-то операторы, которым нет полноценной замены?
это не предупреждение, а “мысли своеобразного анализатора кода”. всё таки “Здоровье кода” используется больше новичками при обучении, а большинство задач действительно не требуют глобальных переменных. однако, от части я согласен, что этот анализ не совершенен и он не учитывает ситуаций, где глобальные переменные использованы разумно. наверно имеет смысл сделать настройку, где он вообще будет отключаться, ибо для опытных пользователей не нужен(если нет планов по его развитию конечно)
а в чём проявляются существенные отличия, которые, к тому же, не позволяют полноценно работать с неуправляемым кодом? развивать что-то большее только ради совместимости, по-моему, будет тратой времени
UPD: и зачем всё это конкретно Вам? Вам нравится работать именно на pabc.net? Или всё это надо для какой-то совместимости? Которая что, опять же, даст?
Дело не в экономии 4 или 8 байтов памяти, дело в сокращении количества кода. Если описание переменной i только одно, то в заголовки циклов не нужно будет добавлять слово var, например. Разве плохо?
А, ну да, я забыл про эту тему. Админ сказал, что используется готовый компонент текстового редактора, где BOM прибит гвоздями.
Тем что при переносе готового кода придётся его переделывать. readstr есть в спецификации паскаля, а string.ReadInteger там нет.
Некоторые штуки оформляются именно как предупреждения. Я правда не помню точно какие именно.
Ну например в преобразовании типов указателей. По идее явным кастом все указатели должны преобразовываться друг в друга, так как размер у них одинаковый.
Например, чтобы школьник мог дома писать программу и пользоваться Free Pascal для отладки, а в школе она бы запустилась при открытии файла в PABC .NET и без всяких предупреждений, если она корректная.
По-моему, пишет трансгендер-бабушка, которая уже всех достала на лавочке. Редкостная хрень.
Нет
Нет
BOM добавляется для единообразия. Это сознательный уход от ASCII-старья. Студия тоже так делает. Более того, другие текстовые редакторы при открытии файла поймут, что это файл с кодировкой UTF8 и в той же кодировке его сохранят. Это важно.
В профессиональных языках программирования переменные описываются перед использованием в локальном блоке. Надо к этому приучать сразу, поэтому предупреждения обязательны.
ну это обычное дело. при разработки код меняют зачастую даже когда с одной версии языка на другую переходят. а тут диалекты… но если есть такое желание, то можете написать модуль, в котором соберёте подпрограммы, которые, по-вашему, обеспечат совместимость. я думаю, его даже добавят в инсталят. только вот сколько реальных проектов, которым требуется именно перенос и дальнейшее развитие по принципам pabc, а не просто ide’шка поновее и пара функций .net? я пока не вижу особо желающих переводить проекты. если бы кто-то действительно хотел, то их бы не остановили такие моменты. но, естественно, им было бы желание помочь и силы были бы потрачены не зря.
опять же, какая от этого польза работе с неуправляемым кодом? да и эту особенность кто-то широко использовал? в каких ситуациях это помогает, а не приводит к трудноуловимым ошибкам?
это та самая ситуация, когда пытаешься организовать себе геморой. если стараться, то он обязательно возникнет. придётся всё таки договориться, либо все работают на pabc, либо на fpc.
надо просто привыкнуть, что в разных диалектах пишут по разному. если в fpc кто-то начнёт юзать статические массивы из TP, где они явно не подходят, или ещё лучше воротить пародии на динамический массив с помощью указателей, то какая будет Ваша реакция? также и мы, когда видим, что переменные, которые используются исключительно в теле цикла(речь даже не про переменную for), описаны за километр до него впадаем в ступор. для нас это уже не интуитивное поведение. сразу возникает ощущение, что от этих переменных что-то зависит в других частях кода, что усложняет понимание. можно говорить, что fpc не устарел и так далее, однако нужно признать, что в сфере стилистики кода pabc существенно продвинулся по отношению к другим диалектам. и приземлить его уже не получится
а с какой целью этот абстрактный школьник пишет на fpc, если знает, что спросят на pabc? это абстрактный линуксоид, который не смог без ide? сомневаюсь, что таких ситуации достаточное количество, что бы активно развивать совместимость. в конце концов проще создать ide под линуху, чем сейчас и занимаются
Ну хотя бы потому что fpc не требует тонны зависимости и довольно просто устанавливается. И лучше совместимость с официальной спецификацией языка Pascal.
Пожалуйста, пусть делает. Может быть подскажу ему как сделать лучше, если смогу.
Смотря где. Если в общем блоке описания переменных конкретной подпрограммы, то вполне понятно почему они там.
Ну да, но тогда как убедить учителей поставить на школьные компьютеры не только abc, но и fpc? А что насчёт КЕГЭ?
readstr не получится реализовать в подпрограмме, поскольку у неё произвольное количество параметров, как у read и readln.
Текстовому редактору никакой BOM не нужен для распознавания UTF-8, сама кодировка имеет такую структуру, что вероятность того что текстовый файл в какой-то другой кодировке прочитается как валидный UTF-8 ничтожно мала. Вот с UTF-16 такая проблема есть и собственно для этой кодировки BOM и был придуман. Это Byte-Order-Mark, то есть метка порядка байтов. А в UTF-8 никакой неоднозначности с порядком байтов нет, а значит и метка порядка байт не нужна.
И что же вы называете ASCII-старьём?
тонны зависимостей это .NET FW, который в большинстве случаев уже установлен?
а зачем их убеждать? что они предложат, на том и работайте. это называется “в чужой монастырь со своим уставом”.
делать-то пусть делает, только вот современному программированию это никак не учит. такого рода проблемы давно остались в прошлом и вытаскивать их из могилы толку нет. а одной из сфер деятельности, которую покрывает pabc всё таки является образование. так к чему же поощрять решения допотопных времён?
да банальный пример, когда переменная нужна в теле цикла в качестве буфера(при ручном обмене значений хотя бы). на кой ей быть глобальной и описанной за 100 строк кода до цикла? или предлагаете каждый чих в подпрограмму выносить?
а что, все недостающие подпрограммы требуют особой обработки компилятором?
Тогда нужна совместимость с тем, что используется дома — то есть с fpc.
Ну вообще-то правило декомпозиции кода — если подпрограмма не помещается полностью на экран (80x25 символов), значит следует задуматься о том, чтобы её разбить на несколько. Каждая функциональная часть программы должна быть в отдельной подпрограмме.
В основном проблема несовместимости как раз в таких вещах, которые требуют вмешательства в саму среду, то есть отсутствие “магических” примитивов вроде readstr и специальных переменных и отличия синтаксиса.
просто дома ставите то же, что поставлено в школе. зачем осознанно создавать себе геморрой?
следует, но не обязывает разбить. не в каждой ситуации создавать дополнительные подпрограммы действительно необходимо
может список какой есть? хоть посмотреть чего “так сильно не хватает”. хотя опять же, сомневаюсь, что если даже весь его реализовать, то кто-то поспешит переводить свои проекты. а делать это для новых проектов – вообще бесполезно
вообще, если честно, то я не вижу проблем в совместимости когда речь идёт о школьных программах. из личного опыта: практически год сижу на киберфоруме. за это время какого только старья там не повидал, а случаев, что бы что-то не компилировалось – единицы
Это неудобно из-за зависимостей. Вначале надо mono какое-нибудь ставить и только потом компилятор pABC. А остальное кроме компилятора вообще не работает как надо. Да и в целом fpc лучше подходит для изучения языка Паскаль.
Верно. Но всё равно вероятность что блок описания переменных окажется в более чем сотне строк от места их использования невелика. Если у вас есть процедура не влезающая не только в 25 строк, но и даже в 100, то уж точно следует что-то отделить в отдельную процедуру или функцию.
Готового списка нет. Но вот давайте простейшую программу рассмотрим. Классика, решение квадратного уравнения. Три коэффициента удобнее брать из параметров командной строки. Не знаю, почему в школе традиционно учат писать код вроде "Введите a: " … "Введите b: " и тд, это же неудобно. Если возникает ошибка, то нужно выдать соответствующее сообщение в stderr и завершиться с ненулевым кодом. Если всё верно, то выдать один или два корня на отдельных строках в обычном режиме и если был задан ключ -v или --verbose, то вначале написать само квадратное уравнение, потом в полной форме что-то вроде x1=… x2=… тогда как в обычном режиме только числа. Если есть ключ -h или --help, то выдать справку с параметрами. Если заданы неподходящие параметры, то предложить запустить программу с ключом --help.
./square_solver 1 -2 3
Например что-то вроде этого должно будет решить уравнение x²-2x+3=0
Попробуйте это написать на паскале так, чтобы код работал и в pABC и в fpc без модификаций.
ну так если школьник сидит на линухе, то ему и mono поставить – раз плюнуть, и консольный компилятор как родной должен быть. да и линукс в какой-то мере это тоже создание себе проблем в обмен на больший функционал(?).
ну так ide уже пилят, как отмечено выше
опять же: можете считать как угодно. но из-за этих убеждений никто не обязан устанавливать дополнительные среды в школе, а тем более менять диалекты. если каждый ученик в школе начнёт требовать определённых порядков, соответствующих его убеждениям, то начнётся бардак.
к сожалению, если рассматривать опыт киберфорума, то ситуация, где переменные слишком далеко – обычное дело.
давайте посмотрим на школьную программу. если реально таких задач нет, то зачем на них ориентироваться?
да и список был нужен не для того что бы убедиться в различиях диалектов, а что бы представлять что действительно активно использовалось и не может быть переведено простыми путями
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021