Собственно это и предлагается сделать (Использовать универсальные методы)! В платформе NET уже встроено всё необходимое. Непонятно, так ли сложно написать Console.ReadLine вместо Readln? А отказ от системного модуля именно это и даст. Куча различных методов, выполняющих практически одно и то-же - это нерационально.
Универсальность - все таки в контексте существующего ЯП. Конструкция read/readln в стандарте языка Pascal есть, и выпиливать ее нельзя. Как и write/writeln. Даже отключаемым параметром. Именно они являются каноничным, универсальным методом считывания/записи в стандартный поток, а все остальное в этом контексте - сахар (readReal), либо потроха (System.Console.ReadLine). На самом деле, слабо понимаю суть разговора. PABCSystem не занимает существенного места в оперативной памяти компьютера на целевых платформах (.NET может запускаться только на Windows, причем используемая версия фреймворка требует Windows, который рекомендует не менее 2 ГБ RAM). Наличие/отсутствие ее в программе не сделает никаких заметных изменений в размере получившегося файла для любой вменяемой по размеру кода программы. Одни ресурсы для иконок займут 90% размера исполняемого файла платформы .NET - они все-таки достаточно малы. Стоит также понимать, что загрузка образа исполняемого файла в память не займет там места больше, чем он сам. 99,9% выделяемой памяти выделяется непосредственно вызовами операций ее выделения из исполняемого кода, поэтому то, что в дампе памяти валяется неиспользуемый в некотором случае PABCSystem, абсолютно никакой роли не играет. Не может освобождение 20 КБ оперативной памяти помочь в случае System.OutOfMemoryException (или как там?), если код написан левой рукой, растущей из седалища, и постоянно leak’ает память.
К слову, выкинуть PABCSystem, и я не понимаю, к чему этот язык. Просто недоделанный (см. последнюю редакцию до-диеза) диалект C#, в котором скобки заменили на begin/end. Почему тогда просто не писать на C# [то, что я Вам предлагаю сделать]?
Для сравнения предлагаю взять две программы:
program test;
begin
while true do begin
end;
end.
и
class WhileTest
{
static void Main()
{
while (True)
{
}
}
}
Запустить каждую по очереди, и сравнить, сколько памяти они занимают. В режиме компиляции Release при запуске без управляющей среды. Вангую, что разница будет менее, чем в килобайт.
Если вы откомпилируете оба файла и сравните их размеры, то будете неприятно удивлены размерами паскалевского файла. Отчасти это и есть причина недовольства. Код на C# менее читабелен, чем на Паскале, поэтому отключение PABCSystem не сделает C# из Паскаля. В таком случае C# тоже можно считать недоделанным, ведь он не унаследовал ни одной библиотеки из C++, хотя их там было несметное множество! > "Конструкция read/readln в стандарте языка Pascal есть, и выпиливать ее нельзя. Как и write/writeln. Даже отключаемым параметром. Именно они являются каноничным, универсальным методом считывания/записи в стандартный поток, а все остальное в этом контексте - сахар (readReal), либо потроха (System.Console.ReadLine)." Языки эволюционируют, меняются. Эти методы использовались в старых версиях языка для обучения программированию. При профессиональном использовании они не нужны хотя бы потому, что программы пишутся под WindowsForms, следовательно консольные конструкции там не нужны. Кроме того, для некоторых программистов важно иметь чистый код (не только исходный но и машинный), не замусоренный пустым содержимым.
Исполняемый файл моих проектов на работе (не .NET, впрочем) обычно не занимает менее 1-2 Мб - за счет ресурсов. Сборка со всеми зависимостями проекта - обычно в пределах 300-400 Мб. Нет, не буду.
Текст на английском менее читабелен, чем на русском? Предлагаю пофилософствовать на эту тему…
От С/С++ С# унаследовал только базовый синтаксис (и то, в крайне модифицированном виде). Программа исполняется под виртуальной машиной, не имеющей ничего общего с нативным кодом, с которым оперирует С++. Посему данный аргумент - не аргумент, а результат непонимания того, что же является языком компилируемым, интерпретируемым, и JIT. Советую погуглить - станет ясно, отчего С# попросту неспособен что-либо “унаследовать” из библиотек, написанных под С++. Для напрыгнувших умных: System.Runtime.InteropServices и связанный с ними unsafe-код - велосипед с костылями вместо колес. C# лучше сравнивать с Java - именно от него он большую часть “фич”, целевую аудиторию программистов, решаемые задачи унаследовал. Ну, как унаследовал. Microsoft это хорошо умеют делать. Это уже тема, правда, другого разговора…
Эти методы использовались для написания самых настоящих энтерпрайзных решений. Насчет современного использования за пределами консоли - через интерфейс read/write/readln/writeln в оригинальном Паскале происходит работа с файлами, тем самым каноничным образом. Не одной консолью Паскаль гордится.
Программы уже лет N (5?) не пишутся под Windows Forms. Для этого есть WPF, UWP, и прочие, более современные решения. Windows Forms - технология, с которой Микрософт все никак не могут стащить большую часть стагнирующих кодеров, посему до сих пор выпускают апдейты. но вот новых фич уже не будет. Никогда. А личное мнение - все это мусор, и в условиях современной конкуренции программистов надо кодить так, чтобы одна программа компилировалась под все устройства разом, с поддержкой всех популярных операционных систем. Как вариант - Qt, т.к. есть версии для мобильных устройств Android/iOS, кроссплатформенна на декстопах (Win, Mac, Linux). Привязывать себя к .NET - означает, оставить себя без самого денежного рынка в истории цифровых технологий - мобильного. И не надо мне тут рассказывать про Xamarin - дохлый проект в силу того, что никто не будет специально под него сотни тысяч строк кода общеиспользуемых библиотек переписывать.
Вывод в stdout/stderr - один из самых стандартных способов доставки отладочной информации до пользователя/программиста. Нужны. Ожидаю вопрос “есть же дебаггер”. Нет, нету. Если ошибку можно выловить лишь из статистических данных [читай: требуются десятки/сотни/тысячи вызовов], но не из единоразового исполнения программы - никакой дебаггер не поможет. Лог-файл не всегда поможет, т.к. его сложно синхронизировать с тем, что происходит в формах интерфейса, когда программа уже закрыта.
А как, лучше самому написать, к примеру, TLD, или воспользоваться, к примеру, OpenCV? А то с ним целая куча “пустого” кода насобирается… Того самого - машинного! А уж если в opencv_world скомпилировать, так вообще - боюсь!
А если серьезно - нет таких программистов. По крайней мере, после первого-второго курса учебного заведения. Раньше - возможно. Только они продаваемый код не пишут.
Я хорошо знаю, что такое компилируемый и интерпретируемый язык. И JIT тоже. Почему бы не сделать с Паскалем то же самое, что и с C++? Унаследовать только базовый синтаксис? Для работы с файлами также есть всё готовое. Находится оно в IO (System.IO). Причём возможностей там побольше будет (сам сейчас работаю там, от “стандартов” отошёл именно из-за ограниченных возможностей). Для WPF, UWP точно так-же, как и для FindowsForms, консольные методы ни к чему, кроме того, попытка их использования приводит к ошибке выполнения (Увы, многопоточные программы не ладят с консолью). Предлагается опционально отключать стандартный модуль, не удалять. Т.е. если хотите пользоваться стандартным языком-просто пишете код, хотите профессиональным-пишете сверху директиву, например {$UsePABCSystem False}, и работаете как на С#, только с Паскалевским синтаксисом. Кстати, где-то в описании (или в презентации) языка, было написано, что PascalABC.NET-это C# с Паскалевским синтаксисом. Официально.
Есть много задач (по крайней мере, в школьной информатике), требующих работы с цифрами натурального числа. Это нахождение суммы и произведения всех цифр числа или их части, удовлетворяющей условию, отбор чисел, цифры которых отвечают определенному условию (например, не более трех одинаковых цифр в числе), анализ цифр числа на определенных позициях и т.п… Предлагаю добавить расширение для типов integer и int64, возвращающее цифры числа в виде динамического массива integer. Примерно вот так:
// PascalABC.NET 3.3, сборка 1547 от 07.10.2017
// Внимание! Если программа не работает, обновите версию!
function ToDigits(Self:integer):array of integer; extensionmethod;
begin
var St:=new Stack<integer>;
while Self>0 do begin
St.Push(Self mod 10);
Self:=Self div 10
end;
Result:=St.ToArray
end;
function ToDigits(Self:int64):array of integer; extensionmethod;
begin
var St:=new Stack<integer>;
while Self>0 do begin
St.Push(Self mod 10);
Self:=Self div 10
end;
Result:=St.ToArray
end;
begin
var n:=123456789012345;
Writeln(n.ToDigits.Sum)
end.
Ага, вот потом результатом “работы” таких функций станут программисты, которые пишут
int a = 555555555555;
if (Convert.ToInt32(a.toString()[5]) == 0) ...
Их и так хватает. Нет уж, пусть разбираются с разрядами… mod и div - не самые сложные в понимании операции.
Не станут. Разве только недоумки. Если нужно работать с цифрами, как с символами, есть n.ToString.ToCharArray
А Ваше
-это не более, чем злобствование “сибоярина”, как Вы любите выражаться, по поводу необходимости в С/С++ самые простые вещи делать вручную. Но не все, пардон, обожают удалять гланды через задний проход.
Предлагаю потестить, насколько проседает производительность программы, в которой div/mod заменили на ToString. Это грубейшая ошибка, за которую бьют. Если уж добавлять API, то вида Integer.GetDigit(index). Или, как вариант - implicit operator[Integer].
ToString.ToCharArray - то же самое, абсолютно. И так писать нельзя.
Зачем заменять div/mod на .ToString? Я же написал: “Если нужно…”. Далее, кто сказал, что цель PasccalABC.NET - оптимизация рантайма? И последнее - выигрыш пары миллисекунд ценой лишней даже пары минут трудозатрат - вот это действительно в наши дни грубейшая ошибка. За которую не просто бьют - могут выгнать с работы, если часто повторять.
Выбираем любую задачу, в которой это нужно сделать более одного раза. Получаем не пару миллисекунд, а несколько десятков секунд работы процессора. Теперь представим, что это происходит в GUI-потоке (а ЦА PABC.NET про потоки не знает, поэтому будет в нем), и увидим безбожно тормозящий интерфейс, потому, что человек не знает базовых принципов. Чрезмерная оптимизация - зло, но ее полное отсутствие - зло не меньшее.
Вы не путаете целевую аудиторию? За несколько десятков “лишних” секунд процессор сделает около 300 гигафлопсов, а на целочисленной арифметике и того больше. Это какой же должна быть задача? А тот, кто программирует GUI-потоки - он не станет получать цифры целого числа. Кроме того, операции div/mod никто не отменяет.
Вы забываете, что синтаксический сахар вводится не для системщиков, а для массовой аудитории и экономии времени преподавателей при объяснении алгоритмов.
Тут есть одна проблема. Вместе с этим отключатся типы integer, real, string и т.д. То есть, чуть менее чем всё.
Кроме того, лягут кортежи, множества, файлы, потому что их работа завязана на системные функции, находящиеся в PABCSystem. Еще раз: прямо в компиляторе есть вызовы функций из PABCSystem. И они там в компиляторе размазаны равномерным тонким слоем.
Поэтому выкусывание PABCSystem - это смерть. Правда, быстрая.
Нет проблем. Но в стандартной библиотеке делать не будем. Причина проста: захламляется количество стандартных методов по точке. Да и задача не такая распространённая. Если Вы обратили внимание, то стандартный модуль не содержит возможности для начинающих - он содержит универсальные возможности.
Добавлять не в стандартную смысла нет. Любой uses во многих случаях делает решение “вне закона”. Например, требование олимпиад - никаких uses/#include
У нас уже сейчас вот получилась большая библиотека, даже сам факт существования которой очень проблематично довести до пользователей. На этом фоне создавать другие подключаемые библиотеки пока особого смысла не просматривается.
Лучше так:
function ToDigits(Self: integer): sequence of integer;
begin
if Self = 0 then exit;
yield sequence ToDigits(Self div 10);
yield Self mod 10;
end;
begin
ToDigits(12345).Print;
end.
И поместить эту радость в какой-нибудь дополнительный модуль. Только вот не знаю в какой. Так Вы все задачи поперерешаете, которые мы даём по начальному программированию 
Да Вы что! И даже
#include <iostream>
нельзя?
Эти олимпиадники - сущие маньяки!
1 лайк
Нет, не , конечно, это же фактически системная библиотека. Но STL уже нельзя, например.
Давайте вспомним, что Вы рассказывали на своих лекциях по повышению квалификации, видео которых выложено на ЮТьюб и ставших весьма популярными. В частности, Ваши слова о том, что достаточно показать один раз “внутреннюю кухню” той же сортировки или устройство стека, а далее пользоваться готовыми объектами и вызовами.
По поводу захламленности точки. Мне подумалось, что как раз кое-где нет функциональной полноты. Мы можем разобрать строковое представление числа на символы, представляющие цифры и даже превратить эти символы в цифры, но почему-то не можем впрямую разобрать на цифры само число.
// PascalABC.NET 3.3, сборка 1547 от 07.10.2017
begin
var s:='1234509876';
var a:=s.ToCharArray; Writeln(a);
var b:=s.Select(c->c.ToDigit).ToArray; Writeln(b);
end.
```[quote="Admin, post:360, topic:143"]
Да и задача не такая распространённая.
[/quote]
<img src="/uploads/default/original/2X/0/0e74bb042a4c8d2c326e9d5eb9e5f853adfa5f20.jpg" width="528" height="500">
Я могу сделать выборку за ОДИН день и будет видно, распространенная это задача или нет)). Но думаю, Вы мне поверите на слово.Вот это меня сильно беспокоит. Я думаю, Вы ошибаетесь. Неужели в олимпиадах нельзя использовать STL? Тогда грош цена таким олимпиадам.
Можно. И на школьных, и на студенческих.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021