Ошибка в подсветке.
вырвиглазный темный фон с белыми буковками еще более ущербен.
1 лайк
Кастомизация цвета и фона в редакторе не имеет никакого толку. Если реализовывать, то именно темы, чтобы вся среда была серой, а не только редактор. А для тем надо иконки рисовать и взять из других открытых IDE. Вообщем мороки много.
1 лайк
А верно ли работают Print/Println для последовательности типа Char?
begin Seq('11','22','33').Println; Seq('1','2','3').Println; Seq(string('1'),string('2'),string('3')).Println; end.
11 22 33
123
1 2 3
Ну вот, вышло очередное обновление (опять неизвестно , что там обновили,сколько ни просили писать кратенько комментарий), а я не успел с этим сообщением (((
Похоже, эту ветку форума не читают. Опять обновление вышло, и опять ошибка осталась…
Да, верно. Именно последовательности символов выводятся подряд - без пробелов, расцениваясь как строки.
Но Вы можете передать пробел как параметр.
Вы эту ошибку имели в виду или другую?
К сожалению, после того как основной сайт сломался я не вижу обновления на форуме - форум предоставляет для этого слабый и неудобный интерфейс. Именно этим вызвана некоторая задержка.
Именно эту. Непонятно, чем вызвано такое поведение именно последовательностей символов, а также массивов символов. Фактически, получается еще одна “особенность” при использовании Print/Println, о которой надо помнить. Для всех допустимых типов по умолчанию этот параметр-пробел уже как бы есть, и чтобы выводить их слитно, надо указывать в качестве параметра пустую строку. А с символами нужно поступать с точностью до наоборот: по умолчанию задана пустая строка-разделитель, а для вывода в исходном виде надо явно указать “пробел”. И мы приходим к тому, что надежнее в Print не пользоваться параметром по умолчанию, а всегда явно задавать пробел в качестве разделителя. Тогда одной проблемой меньше будет в голове. Но не проще ли сделать для всех типов одинаковое поведение?
Вообще-то блок «Последнее на форуме», который был на старом сайте, брал информацию 1-в-1 из раздела http://forum.mmcs.sfedu.ru/latest и, таким образом, был полностью избыточен. Я не против избыточности (и сам программировал этот блок на JavaScript), но странно слышать о том, что форум чем-то хуже.
Воспринимайте последовательность символов как строку. Мы именно этого и добиваемся.
А не получается такого восприятия. К символам строки мы можем обращаться через порядковый номер символа, да и то несколько экзотически: в одних случаях они нумеруются с единицы, в других - с нуля. А к символам последовательности по порядковому номеру не обратишься. Знаете, были в истории развития языков программирования такие, которые состояли из сплошных “если - то - иначе” при работе с ними. Надо все время было держать в голове массу ограничений и условностей. Паскаль этим тоже грешил в определенной степени, а PascalABC.Net мало что унаследовал их, так еще и другие добавил. Мне в свое время очень нравилось писать прикладные задачи на PL/1 - там ограничений практически не было, как и в С/С++: если ты хочешь выстрелить себе в ногу - это твое право, не будем мешать. Хочешь присвоить вещественное значение целочисленной переменной? Да ради бога, останешься без дробной части. Хочешь “не глядя” сделать операцию десятичной арифметики с двумя двоично-десятичными числами и ленишься контролировать переполнение - твое личное дело. Попал под ввод идентификатор массива или структуры (то, что в паскале record) - ради бога, вводи данные. Нужна выдача отладочная в точке? Да не проблема, PUT DATA выведет тебе значения по списку в виде <идентификатор>=<значение>. Ах, список забыли указать? Тогда выведет все, что видит программа в данной точке. Надо что-то локализовать? Сделай блок и пофигу, что вне его есть одноименные объекты - тут они будут свои, это не блоки Паскаля, в которых “имя уже описано ранее”. Цикл? Пиши там любые типы переменных, хоть комплексные (ну да, есть предопределенный тип данных такой и математическая библиотека функций к нему реализована) и любой набор условий - зачем помнить про какие то ограничения? Массивы структур и структуры массивов? Да ради бога! Хочется присвоить, а структура разная? А есть опция BY NAME в операторе присваивания и будут присваиваться только одноименные элементы - это не Паскаль, где даже два одинаковых массива, описанные в type двумя разными строками, считаются разного типа… Ой, числовое значение присвоили строковой переменной? А в чем проблема, преобразует к строке. Обратное тоже можно, если строка число изображает. Еще раз - это сильно развязывает руки программисту, когда пишешь коммерческое приложение и времени мало. Определили при описании заодно шаблон ввода-вывода? Ну, теперь можно не заботиться о формате, значение будет по умолчанию выведено так, как описано. Вот так это было…
Вот красиво стал работать Write - этого не отнять. Настоящий полиморфизм ))) Все, что ему попалось “под нож” - все выведет, а если не понравится результат - это уже проблема программиста. Отличный пример того, как можно при наличии доброй воли снимать проблемы.
Мне симпатичен простой и эффективный прием, которым воспользовался Microsoft в Бейсике для индексов массивов: ввел опциональное (с умолчанием) указание OPTION BASE 0 | 1 и благодаря ему программист может явно указать, с 0 или с 1 начинают индексироваться массивы, если явно задать граничной пары, а описать только верхнюю границу индекса. Т.е. можно писать DIM A(m To n)…, а можно DIM A(k)… Нечто подобное и в Паскале могло бы убрать “базар” в индексировании символов строки для и в индексировании статических и динамических массивов. Хотя я понимаю, что нынешнее состояние - желание команды разработчиков свести везде, где только можно малой кровью, нижний индекс к нулю.
Версия // PascalABC.NET 3.2, сборка 1344 от 22.11.2016
Исчезла функция MatrixRandom
В Справке описана также функция MatrixRandomReal - её постигла аналогичная участь.
И, главное, как об стену: сколько не прошу, чтобы хоть где-то давалась информация о том,
что изменяется в очередной сборке - реакции ноль. Случайно обнаружил MatrixRandom.
А сколько всего, быть может, не обнаружено?
Сам написал и сам нашел. Кто-то МОЛЧА взял и заменил в этих функциях Matrix на Matr
А вот за возможности Print для двухмерных массивов и расширения Row, Column - ОГРОМНОЕ ЧЕЛОВЕЧЕСКОЕ СПАСИБО!
1 лайк
Какие-то странности с GraphABC: есть основная программа и мой модуль, использующий GraphABC. Результаты работы программы сильно разнятся в зависимости от того, подключён ли модуль в основной программе. Полный пример прикладываю. ImageMatrix.pas (2,0 КБ) task-01.pas (138 Байт)
1 лайк
Видимо из-за того какая процедура берется в основной программе. если GraphABC подключен, то стандартная DrawRectangle из него, если не подключен, то аналогичная с этим именем из библиотеки. Проблема с сортировкой подключаемых ресурсов видимо, какой приоритетней использовать.
UPD. действительно, если в основной uses местами поменять - то все начинает нормально работать. Не знаю уж правда, баг это или фича) по мне баг все-таки.
Вы использовали одноименные с GraphABC процедуры. Попробуйте для начала поменять в своих количество параметров (например, вставить еще один, пусть и ненужный), тогда произойдет перекрытие.
Я согласен, что ожидаемый эффект использования собственных объектов в программе всегда таков, что мое частное определение должно иметь приоритет перед общим. Но, возможно тут есть какие-то особенности, на которые нам могут указать только разработчики.
Да, написали о последних изменениях в ЧтоНового
2 лайка
Это не баг. Там использованы одноимённые функции с одним набором параметров. Поиск имён по правилам Delphi осуществляется вначале в текущей программе, а потом во всех модулях в порядке СПРАВА НАЛЕВО. Первым подключённым всегда считается PABCSystem, поэтому в нём поиск осуществляется в последнюю очередь
А нельзя привести пример использования Sort(a,cmp) ?
В последней версии, такое недоразумение уже исключено ?
type a=class public function fun:=3;virtual; end; begin end.
А просто ввести и посмотреть?
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021