При пошаговом выполнении программы невозможно ни сфокусироваться на окне “Графика WPF”, ни свернуть все окна.
Готово, ссылка под цитируемым сообщением.
Да, забыл поставить not
перед Odd(i) then
.
“IDE-ветка” — это https://github.com/pascalabcnet/pascalabcnetide? В противном случае я совершил ошибку, создав 7 нижеприведённых Issue в https://github.com/pascalabcnet/pascalabcnetide/issues :
- https://github.com/pascalabcnet/pascalabcnetide/issues/185
- https://github.com/pascalabcnet/pascalabcnetide/issues/186
- https://github.com/pascalabcnet/pascalabcnetide/issues/187
- https://github.com/pascalabcnet/pascalabcnetide/issues/188
- https://github.com/pascalabcnet/pascalabcnetide/issues/189
- https://github.com/pascalabcnet/pascalabcnetide/issues/190
- https://github.com/pascalabcnet/pascalabcnetide/issues/191
i.IsEven
Я давно изменил if not Odd(i) then
на if i.IsEven then
в последующих упоминаниях программы.
Это вообще ошибка? Для неё тоже создать Issue?
Я создал: https://github.com/pascalabcnet/pascalabcnetide/issues/192.
Думаю, нет
С ReadLexem
можно удобно читать 1 слово из ввода, вместо того чтоб читать всю строку, резать её на массив слов и потом копаться в массиве:
begin
'Введите 2 слова:'.Print;
var w1 := ReadLexem;
w1.Println;
var w2 := ReadLexem;
w2.Println;
end.
А нельзя ли ему, как всем остальным Read*
, параметр для строки-приглашения к вводу, чтоб не выделять его в отдельную строку?
ReadLexem нами создавалась как такая внутренняя. Странно, что это кому-то сильно нужно
Я понимаю, это в основном для личной реализации вещей вроде ReadUInt16
, если кому то вдруг такое понадобится.
Но читать ввод по 1 слову тоже полезно! И ReadLexem
уже делает именно это. Даже пробелы удаляет до и после слова.
Предлагаю обсудить целесообразность расширения ## и ### в конце нулем: ##0 или ###0 …для нумерации срок с 0, чтобы отдельно инструкцию компилятору не писать
Здесь надо вовремя остановиться.
Мы писали ## для командного режима.
Выяснилось, что это страшно востребовано с другими целями Вы - третий или четвёртый с подобным предложением
Еще как востребовано. Особенно в контексте Компьютерного ЕГЭ
Тут стоит крепко задуматься, что такая нумерация даст. В паскалевских строках классически нумерация символов идет от единицы. И на этом построены многие старые алгоритмы и программы, опубликованные в Паскаль.
А главное, сейчас в РАВС более сотни подпрограмм и методов для работы со строками. Методы, как статические, так и экземплярные всегда предполагают, что строка индексирована от нуля. Все функции и процедуры, а также срезы, всегда предполагают, что строка индексирована от 1. Фактически, директива {$string nullbased} переключает нумерацию символов в строке на идущую от 1 или от 0 и работает это для одного единственного случая - обращения к единичному символу строки, как к элементу массива.
Нагрузить директивы ## и ### способностью управлять директивой {$string nullbased} - это заставить человека, читающего код, вспоминать о том, что тут еще и с индексами строк могут играться. Когда директива написана, по крайней мере ясно видно. Но это мой персонально взгляд, потому что я не пользуюсь этой директивой. Кроме того, решит ли это проблему для случая достаточно большого кода, где использовать ## и ### не рекомендуется?
Ситуация со строками в Паскале вообще кошмарна для новичка. Есть строки размерные - статическое наследие ТурбоПаскаль и просто “строки”, современные и динамические.В размерных, “коротких” строках - там все ясно, они от 1 проиндексированы. Уже в Дельфи были “длинные” строки PChar (нуль-терминированные), но и они тоже индексировались от 1. Cтроки в .NET - класс string - индексированы от нуля, потому все методы этого класса опираются на строки, у которых первый элемент имеет нулевой индекс. Функции, унаследованные от ТурбоПаскаль всегда предполагают индексирование от 1 в целях обратной совместимости. В общем, все это помнить почти невозможно.
Конечно, в целях унификации было бы лучше иметь везде индексирование от нуля, потому что обратная совместимость нужна сейчас только школьным учителям, не желающим переходить на новый уровень программирования.
Вот если бы директива {$string nullbased+} оказывала действие и на те старые подпрограммы Паскаля (Copy, Delete, Insert, LastPos, Pos, PosEx), а также на срезы - я был бы всеми лапками “за”, чтобы эту директиву поднять высоко над головой и ей размахивать. Это сблизило бы обработку строк в PABC с таковой в других современных языках. Я бы даже тогда предложил сделать ее уникальной в модуле и записываемой только в начале кода, чтобы не дергать компилятор туда-сюда. А сейчас эта директива работает подобно дельфийской.
От совместимости с Дельфи остались уже “слёзы”. Может быть, когда-нибудь и наступит день отмены “крепостного права” и РАВС избавится от балласта старых языковых норм.
В общем, все это помнить почти невозможно.
Именно это меня мотивировало сделать такое предложение. Да, это Ахиллесова Пята PABCnet. Я прям физически боюсь писать код, когда мне нужно определиться со значением индекса. Взрыв мозга. И пусть ZeroBase строки будут только из .Net и только в том случае если явно указано ##0.
Я всё не понимаю, чего вы их размерными считаете? Паскаль инициализирует все строки (включая динамические) значением ''
и позволяет редактирование (путём копирования) чтоб было как у старых строк.
Но короткие строки ни на сколько не более размерные, чем обычные.
Да, как минимум для срезов надо сделать. Но, похоже, фикс в 2 строчки тут не пройдёт.
Срезы это сахар, они разворачиваются на стадии синтаксиса.
А директивы, похоже, начинают обрабатываться только при конвертировании синтаксиса в семантику.
Хотя вообще это странно, я всегда думал что директивы компилятора это то, что читается перед тем как начинать обрабатывать код.
А насчёт старых функций работы со строками - с ними будет ещё сложнее. {$string nullbased+}
работает только на 1 файл, то есть в PABCSystem
нумерация всё равно будет с 1.
Поэтому, скорее всего, единственным вариантом будет сделать эти функции - волшебными. То есть по-особому обрабатывать при компиляции. И запретить получать адрес этих функций.
По моему лучше забыть про них как про страшный сон и использовать срезы и всякие .IndexOf
. В любом случае методы > глобальные_подпрограммы
.
Поддерживаю. Оставьте Паскалю Паскалево )
Да, и трудно потом объяснять, почему это падает
begin
var s:= 'abc';
writeln(s[s.IndexOf('a')]);
end.
Срезы тоже с 1 начинаются
Странный комментарий к сообщению из размышлений о том, как сделать чтоб {$string nullbased+}
влияло на срезы строк, чтоб они не начинались с 1. Вы точно целиком читали?
Потому что так разработчики сказали. Я, как автор книг по РАВС, не имею права игнорировать мнение разработчиков и противоречить своими терминами тем, которые установлены, например, в Справке. Это вызвало бы когнитивный диссонанс у потенциального читателя.