ab.com コミュニティ

ご報告ありがとうございます。
確実な仕様確定がなされてない中、コンパイラロジックの改良を行ってしまいました。申し訳ありません。

次回のバージョンアップで、C/C++同様、32ビットまでであれば暗黙的に拡張されるように修正しようと思います。

> C言語もそういう仕様だったと記憶しております。
Cの場合は少なくともint/unsigned int型（Win32では大抵32ビット）までは
無条件に格上げされた上で演算されることになっています。

だからというわけではありませんが、ABもLong/DWordまで格上げしてから演算する仕様にする、
つまり最初のhiraさんのコードも思ったとおりに動くようになっても悪くないと思います。

そうですか。わかりました。
※Ver 4.13.00では問題ないのに、Ver 4.22.00ではコンパイルしたOrangeArchiverが正しく動作しなくなってしまいまして。具体的にどのように仕様が変わったかがわからなければ…。

[quote]> Ver 4.13.00ぐらいまでは正常に動作していたんですが、仕様が変更になったのでしょうか…？[/quote]

たぶん、仕様ではないかと思います。

かならず、式中の一番左のデータ型に丸められているみたいです。
C言語もそういう仕様だったと記憶しております。

ただ、/の場合は特殊な扱いみたいですが。。。
実際のところはどうなんでしょうね。

Dim a As Byte,b As DWord
a=&H10
b=a<<8

Dim a As Word,b As DWord,c As DWord
a=&H1000
b=&H1111
c=a*b

[code]Dim a As Byte,b As DWord
a=&H10
b=a<<8[/code]
なぜかbの値が「0」となってしまいます。演算結果もByte型として認識されているのでしょうか？

[code]Dim a As Word,b As DWord,c As DWord
a=&H1000
b=&H1111
c=a*b
[/code]
このコードでもcは「&H1000」で、期待している「&H1111000」とは異なります。
ちなみに c=b*a とすると正しい結果になります。
また、ByteやWordなど、小さいデータ型を大きいデータ型にキャストして演算に使っても正しい結果が得られます。
(上の例では b=a As DWord<<8 や c=a As DWord*b)

Ver 4.13.00ぐらいまでは正常に動作していたんですが、仕様が変更になったのでしょうか…？
以上 Ver 4.21.00 Ver 4.22.00 で確認(Windows XP Home SP2)。