Начнем с того, что я не спорю. Забавно даже, что сейчас Вы приводите ровно те аргументы, которые приводил Вам я после апробации первого появления срезов (безопасных тогда еще не было). На вторые сутки “битвы” Вы приняли решение добавить срезам возможность захватывать одним краем несуществующие элементы массива и это мысль чуть позднее распространилась на строку. Так появилась модификация срезов, которую разработчики назвали “безопасными”.
Посему я вовсе не предлагаю что-либо менять. Безопасные срезы - это действительно инструмент для начинающих и спешащих, но если разрабатывается что-то чуть более серьезное, например, пишется какой-то библиотечный модуль, я считаю, там надо чуть напрячь “серое вещество” и привести все к обычным срезам вместо безопасных. Алгоритм, который ссылается за пределы объекта - некачественный. Даже если мы там, в реализации, бьем за это по рукам.
В противном случае можно попытаться ответить на вопрос, зачем тогда вообще обычные срезы, если безопасные их покрывают? У меня ответ есть: чтобы шлифовать алгоритм.
Спасибо.
В C# принято какое то странное половинчатое решение: если это первый несуществующий индекс, то исключения нет, а если уже дальше, то есть. Хотел бы я послушать их семинар…
3..2 тоже не работает. Потому что срезы массивов не рассчитаны возвращать пустой массив, это явное свидетельство бага в программе. А пустые строки это нормально.
Нельзя. Поэтому индекс 5 не подходит для строки в 3 символа. Но 4 - это не за границей, это на границе:
Когда по индексу берётся 1 символ, обычным s[i] - берётся область длинной в 1 символ. Если эта область начинается с индекса 4 - она таки выйдет за границу.
Но срез не всегда имеет размер области >=1. Вы разрешаете срезы длиной в 0 для строк - поэтому странно применять к ним то же ограничение что у обычного индексатора.
Дело не в пределах, а в пустых строках. Они не будут появляться в хорошо оптимизированной программе. То есть если писать новый качественный компилятор - надо делать кучу доп. проверок и использовать только ванильные .SubString, .IndexOf и т.п.
Но с такой логикой вот что получается: Есть программы учащихся, а есть сложные программы. А простые программы, значит, программисты со стажем уже не пишут?
Если что - простые <> говнокод. Если в программе на 50 строк будет баг потому что всякие необузданные try или безопасные срезы съели нужную ошибку - исправлять её будет не менее больно чем в большой программе. “Шлифовать алгоритм” нужно всегда и всюду.
Опытный программист всегда пишет код, в котором костыли не требуются: он просто иначе уже не может в силу профессиональных привычек. А если может - пока еще не совсем опытный. Потому что опытный программист знает, что *овнокод - это как карма: один раз написал и рано или поздно, но он тебя найдет. В самое неудобное время, естественно.
А насчет того, что шлифовать алгоритм нужно всегда и всюду - тут и обсуждать нечего. Другое дело, что мы не можем этого требовать ни от школьника, ни от его учителя информатики, поскольку выбора учителей, увы, нет.
Зачем в таком случае нужна сейчас опция /rebuild в pabcnetc.exe и “Перекомпилировать все” в IDE, если нельзя с их помощью полноценно скомпилировать PABCRtl.dll или аналогичную автономную библиотеку? В каких еще ситуациях они реально могут быть полезны (кроме плавающего бага с порчей сборок)?
Зачем вообще нужна pabcnetc.exe в дистрибутивах, если её функционал в таком урезанном виде почти полностью покрывается pabcnetcclear.exe? Ну, кроме работы по маске (только внутри и крайне ограниченно) – что элементарно замещается однострочным батником с FORFILES /m *.pas [/s] /p %1 /c "cmd /c pabcnetcclear @path" – и сомнительного по практичности полуцветного недоделанного интерактивного режима с ручным(!) переключением языков (только внутри!).
Если уж совсем откровенно, то качество и понятность лога, обработка ошибок и аргументов командной строки в нем вообще сейчас ужасны: шаг вправо-влево – ошибка или вообще краш! И весь дальнейший текст в консоли становится розовым…
Общепринятый в Windows параметр запроса подсказки “command /?” мгновенно приводит к краху(!) с попыткой компилировать файл “?”.
Порядок следования параметров в строке прибит гвоздями и при этом не совпадает с оными у его “младшего брата” pabcnetcclear (причем не только сам порядок, но и синтаксис аналогичных опций), что регулярно приводит к путанице, ошибкам и лишней потере времени, особенно при удаленной отладке.
Не имеет опции рекурсивной компиляции файлов, начиная с указанной папки
Работа с масками файлов и путями (абсолютными или относительными – неважно) в командной строке невозможна вообще, только в интерактивном режиме и то ограниченно и не везде. Если указать несуществующую директорию в командной строке – сразу розовый крэш!
В интерактивном режиме с опцией Rebuild=1 почему-то может работать только с файлами в текущей папке, но при Rebuild=0 можно уже писать что-нибудь вроде dir1\dir2\*.pas, но все равно нельзя ..\dir1\dir2\*.pas.
При этом не отфильтровывает исходники автоматически по маске *.pas: может по ошибке пытаться компилировать что угодно и тут же крашнуться, если просто ошибиться в имени файла или маски.
Есть возможность интерактивно менять рабочую директорию (cd), но нет возможности посмотреть в ней список файлов и папок (dir или ls) – работай вслепую!
Статистика по строкам и размеру скомпилированного кода работает вообще не пойми как. Выводит что-то вроде Total: 3 files (123kb,2456lines). Time: 13914,2134ms вместо более читабельного Compiled: 3 files (123 KB, 2 456 lines). Took: 0m 13,9s.
Подробный вывод по умолчанию включен при задании опции /rebuild в командной строке, но почему-то выключен по умолчанию в интерактивном режиме (нужно вручную набирать ShowAllMessages=1).
Автозавершения внутренних команд (их всего 10 пока) нет, приходится все набирать полностью.
Если указать команду-флаг без =0 или =1, не понимает, что достаточно инвертировать значение, вместо этого показывает статистику пустой компиляции, как при неправильно набранном имени файла.
В подсказке указано, что по умолчанию режим Debug выключен [0], а на самом деле он включен и создает .pdb (в командном режиме он вообще неотключаем!).
Команды OutType, Reset, ResetOnCompile нигде не описаны и совершенно не ясно в каких случаях они могут быть полезны.
“Шапка” содержит массу служебной и абсолютно бесполезной для пользователя информации. Но при этом подсказка по опциям неполная – напр., вообще не отмечена возможность задания некоторых параметров сразу через командную строку.
Использование цвета в консоли в простейшем интерфейсе – бессмысленное излишество, причем только создающее проблемы с перенаправлением ввода/вывода.
Выйти из интерактивного режима можно только по Ctrl-C, но об этом нигде не упоминается – догадайся сам.
И это еще не полный список… Серьезно работать с этим мучительно. А pabcnetcclear, хоть и функционально куцый, но хотя бы гораздо менее проблемный. Надо хотя бы параметры командной строки у них сделать синтаксически совместимыми и желательно не зависимыми от порядка следования (может ‘–’ или ‘-’ вместо ‘/’ в кач-ве начала опции?).
Ну вот, выговорился – полегчало! Никого не хотел обидеть, просто накипело…
PABCRtl.dll - он не для непосредственного использования.
/rebuild перекомпилирует свои модули - я уже об этом говорил. С лёгкой руки не разобравшегося @Sun_Serega все стали говорить, что он “бесполезен”
Про “плавающий баг с порчей сборок” я первый раз слышу. Опишите его и напишите Issue. Пока для меня такого бага нет.
По поводу консольных компиляторов - да, хорошо бы чтобы кто-то взялся переписать, устранив какие-то ошибки и неточности и добавив параметры. Но нужно, чтобы старые параметры со старой командной строкой работали - у нас системы олимпиад на это завязаны
pabcnetc.exe - это к тому же еще и интерактивный консольный компилятор. Зачем он нужен лично Вам - я конечно не представляю. Он очень древний - да.
pabcnetcclear.exe - да он писался сильно позже. Еще раз повторюсь - прекрасная идея если кто-то бы потратил силы его дописать и исправить мелкие ошибки и неточности. На мой взгляд, это очень полезное вкладывание сил.
Порча сборок это отдельная проблема. Компилятор привык сувать минимум в .exe, чтоб не перенагружать его. С .dll так нельзя, но разработчики хотели сделать более продуманное решение, чтоб можно выло выбирать - какие модули резать, а какие нет.
Ну как первый раз, если у нас с вами был спор на форуме “надо ли в пользовательские .dll сувать всё содержимое модулей”, который кончился issue #2018 о которой все забыли.
Я всегда думал, что считает только строки которые перекомпилировало. То есть если весь модуль из .pcu взяло - его строки не считает.
Ну, это бред, пользователю не нужны кишки работы с .pcu файлами. Если давать кол-во строк - то целиком.
Я помнил что ещё в 2019 разбирался, потому что с модулем где эта опция была бы реально полезна (OpenGL) - эффекта не было. Тогда я не нашёл в компиляторе части подгружающей rtl в сам компилятор (иначе как из него методы брать) и заметил что этой библиотеки нет в дистрибутивах. Вы подтвердили, поэтому я дальше и не копался. Это что то типа шутки было?
Я читаю то, что Вы тут написали, и не понимаю, о чём это. Ссылка идёт на какие-то старые посты Волобуева, который Соколиный глаз, и там не о том.
Вообще, добавьте в название Issue для import что то более информативное: Чтобы в dll входило всё содержимое модулей - как-то так
А всё же - зачем такая возможность? Казалось бы - пишете себе dll - всё что вы хотите в ней чтобы было - реализуете, вызываете сервисные функции из модулей. Понятно.
Но брать уже готовый модуль и пытаться превращать его в dll нельзя. На C# такого и в голову не придёт - там это нельзя в принципе. Так зачем это здесь?
Это в центре окна. А когда форум открывает сообщение по ссылке - это сообщение оказывается в самом верху окна. Ну, может так будет проще заметить, на что я ссылался:
Вот и я о том же! Это бред, пытаться публично зашить в .dll содержимое модуля. Но сейчас - все классы и глобальные переменные и подпрограммы получают модификатор доступа public.
Таким образом, к примеру, если кто то напишет свою библиотеку вроде WPF и использует в ней модуль OpenGL - каждый пользователь этой библиотеки будет видеть не только то что им надо, но и кишки, которые от рядового пользователя библиотеки всегда должны быть скрыты.
И если б хотя бы это был полный набор кишок - так нет, в библиотеку попадает только огрызок, только то - что было использовано в высокоуровневых методах библиотеки.
Я уже не идеально помню, но:
Я столкнулся с этим в 1 своём проекте (который я всё ещё хочу закончить, когда то), где распространялась .dll и ожидалось что она будет подключаться к другим .Net языкам. Но в неё начали попадать кишки моих методов для создания окон и т.п. Поэтому изначально я был за то, чтоб давать содержимому модулей модификатор internal.
Но кто то (вроде @ibond) сказал что попадание содержимого модулей в .dll как есть - зачем то всё же нужно. И в итоге решили что добавить новый синтаксис с uses будет лучшим решением.
А что мешает его использовать (когда он помещен в GAC) и вне IDE, напр., для более быстрого запуска каких-нибудь маленьких самописных консольных утилит? Такие “зависимые” бинарники можно сейчас стандартно получать через IDE, было бы неплохо, если бы и консольные компиляторы могли такое генерить опционально.
Мне он сейчас нужен только для сборки полноценного PABCRtl – я бы про него забыл как страшный сон вообще. Больно уж я с ним намучился, пока не разобрался в его “особенностях”. А пока экспериментировал с ним, ужаснулся: нет, не его древности, а его общей глючности, непродуманности, странностям и недоделкам.
Скажите, а кто и где реально использует этот интерактивный режим? Это просто была чья-то курсовая или действительно реальный юзкейс. Просто любопытно.
Лезть и исправлять такое кому-то со стороны – дело крайне гиблое и неблагодарное, проще уж новую командную оболочку написать, да только кому оно нужно? Гораздо полезнее и разумнее будет доработать pabcnetcclear /rebuild.
От этого будет уже не теоретический, а весьма практический профит для всего проекта – я имею в виду регулярные, публичные, повторяемые, верифицированные и автоматизированные сборки и тесты, со строгим сопоставлением номера билда и соответствующим ему коммитом, чего сейчас весьма не хватает.
Да, я совсем запарился сегодня – конечно, я имел в виду PABCRtl. Просто я смотрел в открытый код RebuildStandartModules.pas, а думал при этом про Rtl Смотрю, там есть OpenCL/OpenCLABC и OpenGL/OpenGLABC, но нет их *Base вариантов.
Глянул сейчас в код PABCRtl – там вообще нет ни OpenCL, ни OpenGL. Видимо, они слишком большие и редко используемые, поэтому их не включили.
Ну, там вообще много чего нет из того, что поставляется в комплекте и это разумно с точки зрения главной цели – ускорения запуска типовых учебных программ. Хотя, можно ведь самому собрать и зарегать в GAC свой кастомный PABCRtl c нардами и домино
Зачем в _GenerateAllSetups.bat, _RebuildReleaseAndBuildUnits.bat и _RebuildReleaseAndRunTests.bat повторно пересобираются стандартные модули сразу после сборки, подписания и регистрации в GAC свежей PABCRtl.dll?
Нужен ли ICSharpCode.NRefactory.dll в консольном дистре (zip)?
Я уже не помню обсуждение, но я согласен - кишки надо скрывать модификатором internal. Надо аккуратно на это посмотреть и написать Issue - какие именно кишки