HSPTV!掲示板

題名のとおりです。

mes int("$300")

は動作しますが、

mes int("0x300")

は動作しません。

""外したらうまくいきました。

>>田中さん
それではint関数の意味がなくなってしまいます。
strrep使えば大丈夫ですが、少し面倒です。

どうぞ。

#undef int
#define ctype int(%1)	__int(str(%1))
#module
	#defcfunc __int str _s
		s = _s
		if instr(s, 0, "0x") = 0 : s = "$" + strmid(s, 2, 16)
		return int@hsp(s)
#global

mes int("$ffcc00")
mes int("0xffcc00")

>>ht_askさん
確かにマクロを使えば同じように動作しますが、バグ報告ということで。

>バグ報告ということで
http://dev.onionsoft.net/trac/openhsp/browser/tags/3.4/hsp3/hspvar_int.cpp
このページの38行目がint関数の中身ですが、
全くそのような処理のかけらが見当たらないので、
それはバグではなく仕様ではないでしょうか。

もしint("0x300")が768になったら
いままで0だったint("0xenon")/*ゼロ・キセノン*/は
14になってしまうのでしょうか。

>>tds12さん
HDLの説明や、
http://www.onionsoft.net/hsp/v34/doclib/hspprog.htm#EXPRESSION
では$〜だけを特別扱いしているわけではありませんし、0x〜だけ変換できないのは変だと思います。

ゼロ・キセノン(0xenon?)についてはわかりません…
16進数ではないですよね?

0xenonが14ってのは0xEと余計な文字nonと解釈され、余計な文字は消されるので14になるってことですね

この手の関数は左から数値として評価可能なところまで計算するので、
仕様変更にあたってtds12さんがおっしゃっているような問題があります。
（0xeまでなら16進数であると評価できるため）

mes int("12a") ; 12と表示される

int("%1111")でも0なので、$で16進数が変換できたのはオマケだと思います。

> では$〜だけを特別扱いしているわけではありませんし、0x〜だけ変換できないのは変だと思います。
もともとHSPは昔の N88-BASIC を土台に開発が進んできたようです。
ですから最初は「$」文字で16進数を表現をしていて、
そのうちに私のようなC/C++言語の出身者もHSPを使うようになりました。

そこでHSPの作者さんがC/C++言語の出身者さん用に「0x」も使えますよ。
という位置づけで機能強化したのだと思います。

つまり、HSPにおいて16進数表記は「$」が正しく、
「0x」は正式サポートではなく「一部使えますよ」という感じでしょうね。
だから命令や関数の引数には使えるように機能強化してるが、
int関数の文字列から数値への変換まで対応を考えてないか、
対応するのを忘れてしまってるだけでしょうね。きっと。

よって「int関数で"0x〜"のような16進数を変換できない」は、
「バグ報告」よりも「要望・提案」で、すべての命令・関数で
「0x〜」「0X〜」「\x〜」をサポートして欲しいと書き込んだ方が良いでしょう。
↑
私もint関数で「0x」が使えないのは不便ですし、
文字列リテラル内で「\x〜」による16進数を指定が使えないと
poke命令で文字列を作り出さないと使えないので不便だと思ってます。

> ゼロ・キセノン(0xenon?)についてはわかりません…
> 16進数ではないですよね?
これは、C/C++言語と解釈は同じでしょうね。
つまり、HSPの内部処理的には16進整数と解釈して処理するが、
「enon」の「e」でエラーとなります。

a=0xenon

↓

???(1) : error 4 : パラメーター式の記述が無効です (1行目)
--> a=$Enon

このようなエラーですね。

返信が遅れてしまいました。
最初はちょっとしたバグだと思っていて、これほど面倒な問題だとは思いませんでした。
HSPはコンパイル時に0xを$に変換しているのですね。
ドキュメントを見る限り0x〜も$〜も同じように扱っているので、$だけというのは不満ですが…