Du hast mit WORDs gerechnet?! Ich schicke Dir die heilige IEC-Inquisition auf den Hals!
Die Frage ist, was man nun negativ sehen soll: Die Lässigkeit von Codesys oder die Engstirnigkeit der Norm?
Wenn ich mehrere Bits in ein BYTE oder WORD packe, dann will ich doch gerade mit arithmetischen Operationen auf mehrere Bits gleichzeitig zugreifen können.
Und umgekehrt bilde ich mir ein, dass auch heute noch ein "Zahl:=Zahl AND 16#03;" schneller ist als "Zahl:=Zahl MOD 4;".
Das erweckt den Eindruck, dass Du den Begriff "arithmetische" Operationen (Addition, Subtraktion, Multiplikation, Division und Modulo, VorzeichenWechsel alias ZweierKomplentBildung, . . .) ziemlich weit fasst und damit auch die sogenannten "logischen" Operationen (Und, Oder, ExclusivOder, alle Bits Umkehren alias EinerKomplementBildung) einschliesst? "Sogenannte" habe ich gesagt, damit man nicht auf die Idee kommt, die anderen - z.B. arithmetischen - seien unlogisch.
Ich wäre eher geneigt, die Schiebe- und Rotier-Operationen zu den logischen zu zählen, als z.B. UND zu den arithmetischen.
In den "guten alten Zeiten" musste man "nur" wissen, was die verschiedenen Operationen mit den Bits anstellen. Heute muss man zusätzlich wissen, welchen DatenTyp man der Ansammlung von Bits künstlich überstülpen muss, damit der Compiler sein Einverständnis für die gewünschte Operation geben oder verweigern kann.
An der Auswirkung der Operationen ändert das rein gar nichts, nur, man muss länger tüfteln, bis man dem Compiler dies klar gemacht hat.
Wenn dann aber die dafür erforderlichen KonvertierFunktionen nach nicht zu rechtfertigenden Regeln arbeiten und durchaus Zulässiges unmöglich machen, so dass für einfachste Verknüpfungen umständliche WorkArounds gebastelt werden müssen (StichWort: höchstwertiges Bit), dann hört der Spass auf.
Was ist denn dann im EndEffekt wirklich übersichtlicher, verständlicher, leichter nachzuprüfen, leichter erlernbar???
Gruss, Heinileini
