Вы меня неправильно поняли. В том сообщении (
#221) я не спрашивал "почему в ОЛ не исправляется конкретная ошибка с CTU". Я спрашивал почему в ОЛ не встречается подход, когда среда обнаруживает устаревшие конструкции кода и предлагает пользователю обновить их до работоспособных.
Возьмём для примера те же "неявные линии задержки". Сейчас ОЛ 1.9 обнаруживает циклы и говорит "у вас тут цикл". Предлагает ли ОЛ заменить одну из связей на линию задержки? Нет. Могла бы? Могла.
Точно так же: "Вообще говоря, у вас тут используется <<write to FB + CTU>>. Такая конструкция не работает. Хотите заменить её на <<write to FB + CTUD>>?" И варианты <<Да, конечно>>, <<Нет, и так сойдёт>>. Иными словами, само "устранение проблемы" можно свести к тому, чтобы среда просто предлагала пользователю исправить CTU на CTUD (ну или как называется рабочий блок в ОЛ). Т.е. CTU переделывать не нужно, прошивку обновлять не нужно. Достаточно просто на стороне ОЛ сделать замену CTU блока на рабочий. Я не призываю именно к такому варианту решения. Я просто показываю пример, как может приносить пользу механизм "нашли устаревший код и предложили пользователю упростить-исправить".
Если оказывается, что про подобные автоподсказки думали и они не поместились в бюджет, то, конечно, печально. Ну, делали же подкраску циклов из связей. Наверняка несложно было бы за одно сделать и замену связи на линию задержки с подтверждения пользователя.
PS. Про то, почему не решается конкретная проблема с CTU меня не интересует (как я и писал в
#226) и я прекрасно понимаю что такое приоритеты.
Сообщение от Владимир Ситников
