演算結果のデータ型

ActiveBasicのバグと思われる不具合を発見された方は、こちらから知らせていただけると助かります。
返信する
メッセージ
作成者
hira
記事: 203
登録日時: 2005年5月31日(火) 20:14
お住まい: 兵庫県
連絡する:

演算結果のデータ型

#1 投稿記事 by hira »

コード: 全て選択

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

コード: 全て選択

Dim a As Word,b As DWord,c As DWord
a=&H1000
b=&H1111
c=a*b
このコードでも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)。
NoWest
記事: 264
登録日時: 2005年5月31日(火) 10:52
お住まい: 高知
連絡する:

Re: 演算結果のデータ型

#2 投稿記事 by NoWest »

> Ver 4.13.00ぐらいまでは正常に動作していたんですが、仕様が変更になったのでしょうか…?
たぶん、仕様ではないかと思います。

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

ただ、/の場合は特殊な扱いみたいですが。。。
実際のところはどうなんでしょうね。
hira
記事: 203
登録日時: 2005年5月31日(火) 20:14
お住まい: 兵庫県
連絡する:

Re: 演算結果のデータ型

#3 投稿記事 by hira »

そうですか。わかりました。
※Ver 4.13.00では問題ないのに、Ver 4.22.00ではコンパイルしたOrangeArchiverが正しく動作しなくなってしまいまして。具体的にどのように仕様が変わったかがわからなければ…。
イグトランス
記事: 899
登録日時: 2005年5月31日(火) 17:59
お住まい: 東京都
連絡する:

#4 投稿記事 by イグトランス »

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

だからというわけではありませんが、ABもLong/DWordまで格上げしてから演算する仕様にする、
つまり最初のhiraさんのコードも思ったとおりに動くようになっても悪くないと思います。
山本
Site Admin
記事: 535
登録日時: 2005年5月30日(月) 15:08
連絡する:

#5 投稿記事 by 山本 »

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

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