Сообщение от
Владимир Ситников
Конкретный пример: очередь. Т.е. с одной стороны записываем (например, номера опустевших баков), из другой читаем (первый опустел -- его перого и будем заполнять).
В варианте олимпиады под эгидой "нет массивам" это делается как кучка SEL'ов. Начинаются игры "как поддержать очередь на 33 бака и не сломать мозг об SEL".
Да, в качестве игры это, конечно, норм.
Но вот для надёжного решения (а в пром автоматике же нужны именно надёжные решения?) должно быть ясно и прозрачно что это не 100500 SEL'ов, а очередь.
Чтобы не требовалось день изучать схему для осознания того, что хотел сказать автор.
С массивом это было бы так:
1) Объявляем массив для хранения очереди. При объявлении указываем его размер. Нужна очередь на 8? Указываем 8 в объявлении. Нужна на 48? Указываем 48. При этом не приходится добавлять и проводить связи между этими 48 SEL'ами, а просто объявили, что нам нужен массив из этих самых 48 ячеек.
2) Для записи/чтения используем две переменные. Одна указывает на порядковый номер ячейки для записи, вторая -- порядковый номер ячейки тения.
3) Запись это просто взять номер ячейки для записи, записать туда значение, увеличить переменную-индекс записи (ну и обработать случаи очередь переполнена/индекс вышел за границы). Можно себе представлять это как блок-"запись в ФБ" с параметрами "имя массива", "порядковый номер ячейки" и "записываемое значение".
4) Чтения -- берём значение из массива по порядковому номеру. Можно себе представлять это как "read from FB" с параметрами "имя массива" и "порядковый номер ячейки", а на выходе -- "результат чтения".
Очередь, стек, линия задержки, всё это гораздо проще программировать и понимать именно с массивом, а не с месивом SEL/GT блоков.
В общем, сила массива в том, что "количество ячеек" можно указать одним числом, и это исключает ошибки copy&paste, которые могут возникнуть при ручном размножении SEL'ов.
Да и потребление ресурсов у массива должно быть меньше, чем у кучки SEL'ов.
Тут кто-нибудь может сказать: "но макрос STEK это же и есть простое и понятное решение с N входами и N выходами. По названию понятно, что стек. Зачем массивы-то нужны?"
Если возникла такая мысль, то человек ничего не понял.
Вдруг в этом самом макросе STEK какая-нибудь связь неправильно проложена? Как это проверить? Как вариант упражнения: давайте я удалю какую-нибудь связь (нарисую лишнюю) и посмотрим сколько времени уйдёт у "эксперта-электронщика" на поиск ошибки, когда он будет заранее знать, что ошибка есть?
А, если нужен стек не на 8 входов, а на 33? Придётся, ведь, макрос перекраивать. Это как раз прямая возможность накосячить. Как тестировать новосозданный макрос на 33 элемента?
Даже, если имеющийся "стек на 8 элементов" был полностью протестирован (как, кстати? ведь в ОЛ нет автотестов), то новый блок придётся тестировать заново.
Запустить в эксплуатацию и ждать когда взорвётся бак?
В случае массивов же, шансов на ошибку гораздо меньше, ведь для увеличения/уменьшения длины очереди достаточно будет лишь изменить размер массива.
Ответить с цитированием
