Прямо из текста Справки, которую Вы почему-то погнушались почитать: ))))
Чтобы одному динамическому массиву присвоить копию другого массива, следует воспользоваться стандартной функцией Copy:
a1 := Copy(a2);
Будем ждать. Сдавай! (с)
Если уж эта возможность настолько портит нервы, что “как обычно”, почему бы эту возможность вообще не убрать? Оно ж не только на уровне грамматики кашу создает, в голове тоже. Поди-ка поля структур от последовательного вызова методов отличи… Стандарту “старого Паскаля” тут все равно никто соответствовать не стремится, разве нет? Мы тута на работе, чтоб о таких мелочах не думать, даже неконстантные ссылки не используем, чтобы лишний раз указать на смысл аргумента функции:slight_smile:
1 лайк
Но все же, чем меньше будет отходов от стандарта, тем правильнее. К тому же, мы не забыли, что совместимость со “старым Паскалем” пока что должна быть близка к 100%, ибо школьники… ?
Т.е. прекрасны новые широкие возможности и надо их всячески стараться при случае “воткнуть и показать”, но все же совместимость - она пока очень важна.
Ну, как это там во “взрослых” системах делается? 5-6 версий подряд кидается ворнинг с большими красными буквами DEPRECATED, потом убрать. И не обидеть никого, и избавиться от старого (и, по моему скромному мнению, очень вредного) наследия. Если ошибка будет говорящей(т.е. что-то вроде "За вызовом функции без параметров должны следовать пустые скобки. Объяснение данным изменениям здесь: [link]), то и пройдет гладко.
“Ворнинг мне бумага джаммед” (некогда - одно из сообщений болгарского IBM PC XT “Правец”)
Все это уже обсуждалось в другой ветке. И вроде как пришли к выводу, что ворнинги можно делать, но избавляться от тяжкого наследия рано. Ибо как все школьные учебники, поскольку они есть школьный катехизис, содержат пока что именно “тот” Паскаль и получив несовместимость мы вызовем автоудаление продукта PascalAВC.NET из школ.
Ну и главное: вот Вам не нравится возможность не лепить идиотические пустые скобки после имени функции, а мне очень даже импонирует. Тем более, что в свое время довелось довольно долго сидеть в клиентских проектах на VBA, а там пустые скобки при вызове функции факультативны - вот за подобные вкусняшки я мелкомягких ребят уважаю. (“И увидел он, что это хорошо” ©)
{$reference axis_api.dll}
uses AXIS;
...
begin
var IP := '192.168.0.42';
var cam: Camera := Camera.get(IP);
...
for var i:=1 to 100 do begin
cam.nextPosition;
var zoom := cam.zoom;
...
//обработка зума, например, с целью рассчитать примерное расстояние до объекта
//или требуемый угол поворота, дабы свернуть на половину экрана для каждой позиции
//вариантов тут куча
end;
...
end.
Ну, с nextPosition все понятно. Вопрос такой. zoom - это значение, которое моментально считается из поля(например, вычитываемое из камеры в параллельном потоке), или же вызов синхронного сетевого запроса, который повесит GUI-поток на время выполнения? А если кабель отошел, пользователю 30 секунд стандартного таймаута на повисший GUI лицезреть? А там таких 100 
А программист-то и не в курсе… Прошу заметить, что пример-то не резиновый: прямо сейчас тут над обработками данных с камеры работаю.
P.S. Да, оффтоп. Тут пора сообщения в другую тему двигать 
Вы даете в качестве примера фрагмент плохо написанной программы и предлагаете мне угадать, что означает тот или иной фрагмент в ней. По меньшей мере, некорректно. Если это Ваша программа - пишите её так, чтобы было все понятно. Если чужая и Вам доступен текст - разберитесь и вставьте комментарий, чтобы больше не подпрыгивать. Но вообще, если чужая, её в таком виде не должны были к эксплуатации принимать.
Я в жизни принимал участие во многих больших проектах, очень больших. И, поверьте, знаю, какие требования выдвигаются к программным кодам, Этот код для неспециалиста в предметной области, для которой код предназначен, непонятен. А для специалиста - ну пусть он и судит, как надо писать. Но уж точно тут не проблема наличия скобочек.
да, я тоже не люблю вызовы без функций и стараюсь всегда писать (). ибо кровушки попили они изрядно, причем толку от этой “фичи” ноль.
1 лайк
Типичный пример - недавнее “исправление” “ошибки”
a.Select(x->x.ToString)
Это вот проекция куда - на строку или на делегат?
1 лайк
Видимо зависит от пристрастия к тем или иным языкам. Лепить пустые скобки - типично сишная привычка. Т.е. если человек привык писать со скобками - ему хочется эти скобки, если привык писать без пустых скобок - ему эти скобки похуже красной тряпки быку. Вот представьте: я последние ДВАДЦАТЬ с лишним лет не работал с С-подобными языками. Вот они мне не были ни разу нужны по работе. Пустых скобок не писал вообще - так тоже бывает. Попробуйте понять мою точку зрения - будут раздражать после такого периода обязательные пустые скобки?
А нельзя просто не делать одноименных функций и делегатов, если контекст не позволяет распознать, что именно вызывается?
Гхм. Контекста тут как раз Вы не поняли. И проблема тут в том, что здесь нет “двух” сущностей, но есть две интерпретации одной.
Первая дает обычную лямбду: vector<some_type> -> vector<string>
Вторая дает vector<some_type> -> vector<function(object, method): string>
Почему вторая тут “позволительна”? Потому, что без указания непосредственного вызова функции не совсем ясно, является ли метод в лямбде вызовом, либо указателем на метод. Одноименно названных “функций и делегатов” тут нет.
a.Select(x->x.ToString)
Конкретно имею в виду x->x.ToString, который может интерпретироваться и так, и так.
1 лайк
Не всегда слово “контекст” надо понимать столь буквально. Возможно, термин “контекст” я неудачно употребил, рассчитывая, что меня поймут. Я тогда попробую привести аналогию. Вот конструкция на Паскале:
if p1 then if p2 then s1 else s2;
Что здесь имеется в виду?
if p1 then
if p2 then s1 else s2;
или
if s1 then
if p2 then s1
else s2;
Чтобы такую коллизию разрешить, в Паскале принято соглашение; else всегда связывается с ближайшим предшествующим if, т.е. в нашем случае используется первое из возможных толкований.
– Аналогичным образом проблема решалась в языке PL/I: в конструкции IF x1 THEN IF x2 THEN y; ELSE z; конструкция ELSE относится к условному внутреннему оператору. – Так же проблема решается в С/С++ – В предшественнике Паскаля, языке Algol-60, конструкция then if была синтаксически запрещена. – В Basic коллизия then if невозможна из-за требования либо писать однострочный if-then, либо завершать каждый условный оператор конструкцией end if
Может быть, имеет смысл подумать и выбрать какую-то концепцию, позволяющую понять, в каком случае вызывается именно функция, либо делегат.
Вы предлагаете документально оформить стандарт языка? Да, действительно, можно понапринимать пару десятков таких “концепций”, и оформить их в виде некоторого крайне специфичного документа, описывающего стандарт диалекта языка Pascal под названием PascalABC.NET от и до. На чтение такого документа(который, в отличие от гайдов по написанию хеллоуворлда, будет чрезвычайно сложным в понимании для новичка) нужно будет потратить уйму времени, а чтоб уж во всем разобраться - так надо будет вообще пару-тройку курсов по ООП послушать. Так и в чем его смысл тогда, если ЦА - школьники и “моя хата с краю”-настроенные учителя? Честно говоря, крайне негативно отношусь к конструкциям языков, к которым надо подходить с позиции “пойду почитаю стандарт” - что отсутствие пустых скобок, что последовательные if/else без закрывающих операторов. Тут надо еще вспомнить, гг, что большая часть ЦА даже не использует табы/пробелы для оформления структуры кода - куда уж там стандарт читать…А покрыть все случаи получится?
Зато можно будет по любому поводу тыкать “вам на страницу 284 в пункт 463.1”.
Вот для того, чтобы не появлялись многостраничные “гайды по диалектам” и надо придерживаться некоей синтаксической канвы, изначально в языке присутствующей. Писать пустые скобки - это не традиция Паскаля, это появилось только в Borland Delphi. И если такая возможность вызывает коллизии, то нужны пути их разрешения, не вызывающие недоумения ни у пишущего код, ни у читающего его, ни даже у компилятора.
А я-то думал, для кого придумали это смешное RTFM? Теперь знаю: для Вас. )))
Стоит разделять понятие “книги/статьи по аспекту языка” и ISO-стандарта. Вот цитата с сайта isocpp.org:
Q: Why is the standard hard to read? I’m having trouble learning C++ from reading it.
Please note that the standard is not intended to teach how to use C++. Rather, it is an international treaty – a formal, legal, and sometimes mind-numbingly detailed technical document intended primarily for people writing C++ compilers and standard library implementations.
Fortunately, there are lots of good books that do teach how to use C++! See these recommendations as a starting point for high-quality tutorial and reference information about how to learn and use C++.
Подразумевается, что стандарт нужен для разработчиков компилятора языка, а не для конечных пользователей. Если он становится необходимым для конечных пользователей - с языком что-то не так.
Безусловно! Учтем, разве что, что когда были введены в стандарт пустые скобки, Паскаль не знал ни про ООП, ни про функциональную парадигму, ни даже про перегрузку функций. Кстати, такой вот интересный пример. Как себя поведет следующий код?
function expr : integer
begin
expr: = 1;
writeln(expr); //тут рекурсивный вызов или вывод единицы?
end;
Ну, имеется в виду, что даже в старом Паскале данный пример вызовет вопросы - ведь результат совершенно неочевиден. Даже тогда наличие/отсутствие скобок было проблемой, из-за которой было необходимо дописать пару строк в стандарт для разработчиков компиляторов. А уж сейчас, когда количество языковых элементов было увеличено эдак раз в 5, данная возможность ничем, кроме головной болью, не является. Она создает коллизии, в огромных масштабах.
Я вот все пытаюсь понять, что Вы предлагаете? Я предлагаю минимально вмешиваться в синтаксис языка с тем, чтобы сохранить совместимость с предыдущими версиями и объясняю причины этого. Если необходимость такого вмешательства есть, я предлагаю её где-то письменно закреплять, чтобы о ней любой прочитать мог.[quote=“JediKnight, post:577, topic:126”] Учтем, разве что, что когда были введены в стандарт пустые скобки, Паскаль не знал ни про ООП, ни про функциональную парадигму, ни даже про перегрузку функций. [/quote] Стандарта Паскаля не существует, как такового. Нет такого документа. Что до введения пустых скобок - они (снова напоминаю) появились в Delphi (1995), который возник на базе Object Pascal (1986), и последний по-Вашему был не объектным, а для хохмы так назывался, потому что пустых скобок изначально в нем не было. Когда в Дельфи появились пустые скобки, об этом прямо так и писали - чтобы было проще привыкнуть перешедшим с языков С/С++. Не более того.
Вы же вместо предложений стараетесь найти пример, в котором надо напрягать мозг именно потому, что пример этот использует то самое, требующее неких изменений в каноническом паскале О чем я и пишу.
И зачем на С++ ссылаться? Этот язык многократно критиковали такие гранды, рядом с которыми Вас, простите великодушно, даже в микроскоп не видно. Я уж лучше к ним прислушаюсь…
Я ссылаюсь не на С++ как таковой, а на отношение к оформленному стандарту: пользователь не должен лезть в него за объяснениями чего либо, для этого есть более простые и понятные источники.С++, Rust, Pascal, или протокол TCP/IP - не важно.
И будут критиковать, и даже за дело. Но альтернативы ему нет и не будет,
А я тут предлагаю не тянуть за языком наследие 40летней давности, давно отжившее свой век и морально устаревшее. [quote=“RAlex, post:578, topic:126”] Стандарта Паскаля не существует, как такового. Нет такого документа. [/quote] Гхм?
Нет, я показываю пример, в котором программист, вместо плодотворной работы, будет напрягать мозг попусту.
Первый блин - комом.
1 лайк
Согласен, неверно выразился. Стандарт ISO есть, но я не слышал ни об одной точной и полной его реализации.
- Доктор, когда я делаю вот так, мне больно…
- Голубчик, а Вы “вот так” больше не делайте!"
Если человек сам себе злобный буратинка, он может написать еще и похлеще. Вопрос в том, зачем?
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021