То же самое, что и модификатор параметров in из C# - передача аргумента по ссылке с невозможностью изменения.
Если очень коротко, она означает, что данный параметр ведет себя, как константа. Если попытаться изменить его значение, компилятор выдаст сообщение об ошибке.
Косвенно это означает, что другой человек может не беспокоиться, что переданный в чужую программную единицу будет ей изменен. А разработчик программной единицы страхует себя от изменения в коде полученного извне параметра.
Поэтому меня удивляет настойчивое желание иметь возможность в рамках одной программной единицы (которая по определению должна быть скромного размера) создавать локальные константы со ссылкой на то, что иначе трудно их не испортить.
1 лайк
Понял.
Вы с in в C# не встречались что ли? 
Встречался, но сам никогда не использовал.
Интересно, в чем кроется “удобство” писать 17 символов вместо восьми и при этом выводить результаты, потеряв возможность стандартного паскалевского форматирования ? Да еще и uses.System; зачем-то тулить?
писать вместо
begin
writeln('Hello, World!')
end.
по-Вашему “удобно”? Ну, знаете ли…
Требуется стандартное форматирование - используйте Write/Writeln. Если оно не нужно, то пользуйтесь интерполированными строками или string.Format. Второе не хуже первого. В некоторых случаях даже лучше. Это личные предпочтения каждого.
Интересно, в чем кроется “удобство” писать 17 символов вместо восьми
Приведу Ваш любимый аргумент:
никто же не умер
.
1 лайк
Хорошо, что Вы меня цитировать начали. Жаль только, что не к месту. Я это писал по поводу. что не надо трогать того, что есть. В данном случае рекомендовать всем писать такие вирши, подключая библиотеки и использовать интерполированные строки, в которых еще новичкам разобраться нужно, - явно неразумное мальчишество. Главное, непонятно что этим достигается. Преимуществ в в сравнении с Print/Write никаких. Или снова “потому что так пишут в C#” ?
Хорошо, что Вы меня цитировать начали. Жаль только, что не к месту.
Еще как к месту, так как в этом Вы видите катастрофу.
Преимуществ в в сравнении с Print/Write никаких.
Можно оспорить. Зайду вечером и докажу обратное.
1 лайк
Что - то уже страшновато…
Дело в том, что замена writeln на Console.WriteLine при портировании программы на C# - процесс особо медитативный. Кроме того, все эти стандартные паскалевские методы являются обёртками для методов .NET. Это приводит к замедлениям программы, раздуванию бинарных версий программы и ограничениям возможностей. Для .NET языка должны существовать только библиотеки .NET, за исключением громадных алгоритмов, написанных заранее!
А что, все кто пишут на PascalABC.NET, планируют эту писанину портировать на C# ? Согласитесь, для массового пользователя идея “писать вывод длинно и вычурно” лишь имея в виду какое-то портирование - не лучший совет.
А это вообще не имеет никакого отношения к обучению.
А при чём здесь вообще обучение?
Стандартное форматирование Pascal Вы не сможете использовать вне контекста Write\Writeln и Str, что не скажешь об интерполированных строках:
begin
var (x, y) := ReadlnInteger2();
var sum := $'{x} + {y} = {x + y}';
end.
. Главное преимущество интерполированных строк (синтаксического сахара над string.Format) - наглядность. Можно, конечно напрямую использовать string.Format, но наглядность будет меньше. У стандартного форматирования своя область - Write\Writeln и Str, но эта область меньше, чем у интерполированных строк. Я не спорю, что стандартное форматирование также полезно, но это не единственный предлагаемый языком инструмент.
1 лайк
Во-первых, непонятно, где оно еще нужно. Во-вторых, это не повод везде писать сплошные интерполированные строки. В третьих, инетрполированная строка прекрасно выводится любыми средствами языка Паскаль без всех этих Console.WriteLine благоглупостей.
А мне уже надоели Ваши вечные призывы писать на Фортране. И что?
Это личные предпочтения каждого. И Вы никак на них не можете повлиять.
Никто и не спорит. Я лишь сказал, что область применения интерполированных строк более широкая.
Я не призываю Вас писать на Фортране. Квалифицированный программист потому и называется квалифицированным, что он не доит один язык до последней возможности, а знает много языков и для решения задачи применяет тот язык, на котором решение будет наиболее эффективным. Вот о чем речь. Ваша проблема с быстродействием легко решается переходом на Фортран - об этом я и пишу. Не в состоянии этого сделать - ну это Ваша беда.
А, Вам просто хотелось сказать хоть что-то? Потому что зачем говорить о том, что и так известно всем?
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021