Средство для программирования контроллера: Си или МЭК 61131?

Моя личная точка зрения заключается в том, что полиморфизм, по крайней мере, в его сишной реализации, это возможность создать два метода с одинаковыми названиями для реализации действий над разными типами данных. В небольших программах в этом нет необходимости (и так все ясно), а в больших, вкупе с неявными преобразованиями типов и наследованием, приводит лишь к дополнительной путанице.

Возможность же наследования, позиционируемая как способ повторного использования кода, на самом деле позволяет похоронить детали реализации тех или иных классов вместе с воспоминаниями о том, для чего они были нужны :)

Вообще, я не сторонник ООП в сишном его понимании, и всегда предпочитаю писать <FONT face="Courier New, Courier, mono" size=2>my_method (&my_object) вместо <FONT face="Courier New, Courier, mono" size=2>my_object.my_method() :-) Даже несмотря на то, что в данном случае "чистый" C не позволяет контролировать правильность передаваемого указателя (в этом смысле Паскаль - более "безопасный" язык). Прошу понять меня правильно, я не считаю, что ООП бесполезно как таковое. Просто оно, на мой взгляд, не является нужным при решении задач управления технологическими процессами. Его область применения тоже достаточно специфична: базы данных, графические интерфейсы...

Если исходить из того, что графически выраженный "агрегат" представляет собой вектор X=(x1,x2,...xn), то для того, чтобы получить из него другой вектор Y, представляющий собой некоторую комбинацию элементов исходного вектора, то мы должны выполнить преобразование, например, y1=x2, y2 = x1 и т.п. Таким образом, чтобы получить из одного "агрегата" другой, мы должны создать некоторую подпрограмму (функцию или функциональный блок), реализующую это преобразование. Либо делать это преобразование в том блоке, которому этот "агрегат" предназначается. Разве есть другие возможности?

Если я правильно понял, это что-то наподобие механизма "дружественных классов" в C++. Да, такой механизм мог бы добавить описательности языку, но способен также сильно запутать программу, приводя к трудноуловимым ошибкам. Представьте себе, если три функциональных блока связаны между собой такими двунаправленными связями, как будет определяться порядок вычислений?

 <SPAN class=bold>Владимир Е. Зюбин </SPAN>еще одна статейка нашлась из Кирилла-Мефодия...

Чем тащить сюда всякий хлам, вот Вам конкретный пример. Интерпретатор Форта по имени SPF4, со всеми исходниками лежит на http://sourceforge.net/projects/spf/

Лезем в эти исходники и смотрим - как  выполняется интерпретация подпрограммного шитого кода (или, если угодно - байт-кода). Обнаруживаем, что этот шитый код состоит из последовательности вызовов подпрограмм. Оные подпрограммы заранее скомпилированы и лежат в памяти. В сумме все эти подпрограммы и есть SPF4, они организованы определенным образом, и пр, но это к делу не относится, ликбез по Форту Вы можете получить в другом месте, например, здесь http://www.forth.org.ru/

Лезем в эти подпрограммы (исходники) и пытаемся найти в них хоть какой-то намек на "трансляцию перед исполнением". Что мы видим?

Опреатор DUP (или, в терминах Форта - "слово" DUP)

CODE DUP ( x -- x x ) \ 94
\ Продублировать x.
     LEA EBP, -4 [EBP]
     MOV [EBP], EAX
     RET
END-CODE

Тело этого слова состоит из 3-х ассемблерных команд. При интерпретации оператора DUP всего будет исполнено 4 команды:

     call DUP   \ это "байт-код", т.е. вызов нужного слова
     LEA EBP, -4 [EBP] \ а это - работает интерпретатор
     MOV [EBP], EAX
     RET                      \  интерпретатор закончил работу с этим словом,      
                                 \переходим к следующему "байт-коду"

Вы будете продолжать утверждать, что эти 4 команды сначала что-то транслируют, а потом исполняют? Если так, Вы будете нести откровенный бред. Они только исполняют, но ничего не транслируют.

Предположим, Вы скажете "я не знаю Форта, я не знаю что это за слово DUP". Посмотрим что из себя представляют тела других, более понятных слов интерпретатора

<FONT color=#000000>Примеры операторов сравнения

CODE < ( n1 n2 -- flag ) \ 94
\ flag "истина" тогда и только тогда, когда n1 меньше n2.
       CMP  EAX, [EBP]
       SETLE AL
       AND  EAX, # 1
       DEC  EAX
       LEA  EBP, 4 [EBP]
       RET
END-CODE

CODE > ( n1 n2 -- flag ) \ 94
\ flag "истина" тогда и только тогда, когда n1 больше n2.
       CMP  EAX, [EBP]
       SETGE AL
       AND  EAX,  # 1
       DEC  EAX
       LEA  EBP, 4 [EBP]
       RET
END-CODE

<FONT color=#000000>Оператор умножения

CODE * ( n1|u1 n2|u2 -- n3|u3 ) \ 94
\ Перемножить n1|u1 и n2|u2 и получить произведение n3|u3.
     IMUL DWORD [EBP]
     LEA EBP, 4 [EBP]
     RET
END-CODE

<FONT color=#000000>Логические операторы

CODE AND ( x1 x2 -- x3 ) \ 94
\ x3 - побитовое "И" x1 и x2.
     AND EAX, [EBP]
     LEA EBP, 4 [EBP]
     RET
END-CODE

CODE OR ( x1 x2 -- x3 ) \ 94
\ x3 - побитовое "ИЛИ" x1 и x2.
     OR EAX, [EBP]
     LEA EBP, 4 [EBP]
     RET
END-CODE

Достаточно примеров? До Вас еще не дошло, что этот интерпретатор ничего не транслирует, а только исполняет? Если не дошло - Вы безнадежны. Если дошло - то не загрязняйте тред всяким мусором, выкопанным на помойке.

<FONT color=#000000>Кроме того, если  у Вас в голове есть хоть капля здравого смысла, и Вы хоть раз заглядывали в асм код,  сгенерированный Вашим любимым транслятором С (на выбор), Вы должны догадаться, что интерпретатор SPF будет работать не намного медленнее или даже быстрее, чем то, что нагенерил этот Ваш С-транслятор. Поскольку у SPF него нет накладных расходов на манипуляции с фреймами.

<FONT color=#000000>Есть и другие примеры быстрых интерпретаторов. Мне нет нужды приводить их все, потому что для опровержения всего бреда, который Вы нагородили в своей статье и продолжаете нести здесь - мне достаточно привести один-единственный пример. Пример БЫСТРОГО интерпретатора, который НИЧЕГО НЕ ТРАНСЛИРУЕТ, а только и исключительно ИСПОЛНЯЕТ. Что я и сделал.