HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2014
1205
srtmどうして__INCLUDE_LEVEL__がないのか7解決


srtm

リンク

2014/12/5(Fri) 23:56:57|NO.66302

ここでいう__INCLUDE_LEVEL__とは、C++に存在するあの__INCLUDE_LEVEL__である。
また、ここで言うC++のドラフト規格はC++11ということにしておく。

C++を知らない人のために解説しておくと、これは、現在の#includeの深さを表すマクロで、
0から始まり、#includeされる度に1ずつ増えていく、というものだ。

C++には__LINE__や、__FILE__などのマクロがある。これはHSPにも存在する。

私は強くこのマクロの追加を希望する。



この記事に返信する


srtm

リンク

2014/12/6(Sat) 00:10:35|NO.66303

現行のHSPはMSVC実装である。現行のMSVCに__INCLUDE_LEVEL__は存在しない。
おそらくこれが原因だと思われる。

それと、ここからもうひとつ独り言になるが、
HSPにはincludeの深さの制限がかけられていない。
いや、かけられていないというか、つまりこういうことである。

#include __FILE__
このコードは自分自身をincludeするだけのコードである。本来なら無限ループになるはずなので、たいていの言語ではこれ以上はincludeできない、という上限がある。
しかし、HSP3.4ではこのようなエラーレポートを吐かれる。

#HSP script preprocessor ver3.4 / onion software 1997-2014(c) #Use file [hspdef.as] #Error:too many include level in line 1 [test.hsp] #Fatal error reported. #Error:too many include level in line 1 [test.hsp] #Fatal error reported. ~~~~~ #Fatal error reported. #Error:too many include level in line 1 [test.hsp] #Fatal error reported. #Error:too many include level in line 1 [test.hsp] #Fatal error reported.
数十行に渡る同じ内容のエラーレポートが永遠に返されるのだ。これは理不尽だ。
上記のコードを実行できるようにしてほしい(200回ぐらいのincludeでとまってほしい)とは言わないが、せめてこれはどうにかしてほしいものだ。



KOMARI

リンク

2014/12/6(Sat) 00:33:58|NO.66304

2重インクルードを防止するコードは入れないんですか?(・ω・)



zero

リンク

2014/12/6(Sat) 00:58:18|NO.66305

>私は強くこのマクロの追加を希望する。

そのマクロがあると何が良いのですか?
一般的なユーザーにとっては自分自身のファイルをインクルードする必要はまずないと思うのですが。
合理的かつ利用性の高い機能であるのならば、追加されても良いと思います。



Hiroaki

リンク

2014/12/6(Sat) 07:18:24|NO.66307

今すぐほしいのなら
http://d.hatena.ne.jp/chaperatta/20080811/1218457932

> ここでいう__INCLUDE_LEVEL__とは、C++に存在するあの__INCLUDE_LEVEL__である。
> また、ここで言うC++のドラフト規格はC++11ということにしておく。
私の記憶が確かなら、__INCLUDE_LEVEL__はC++標準ではなく、gcc拡張で、C++11にも入っていない気がします

> 現行のHSPはMSVC実装である。現行のMSVCに__INCLUDE_LEVEL__は存在しない。
> おそらくこれが原因だと思われる。
まったく関係がありません。

> 数十行に渡る同じ内容のエラーレポートが永遠に返されるのだ。これは理不尽だ。
> 上記のコードを実行できるようにしてほしい(200回ぐらいのincludeでとまってほしい)とは言わないが、せめてこれはどうにかしてほしいものだ。
> 本当に永遠に繰り返されるのでしょうか?
私の環境では33回分しか出ていないように見えます。
明らかにおかしいスクリプトを仕様どおり(includeの深さは32まで)処理しようとしているだけです。
何が問題なのですか?

> そのマクロがあると何が良いのですか?
たとえば次のような直接実行とライブラリ的利用の両方をサポートするとか
// 共有できる命令の定義
#deffunc hoge ... return #ffunc piyo ... return #if __include_level__ == 0 // 直接実行されたときはここを実行 hoge piyo #endif



skyblue

リンク

2014/12/6(Sat) 12:14:12|NO.66308

C++の標準規格であるISO/IEC 14882:2011を検索かけた所
見つけることができなかったのでGNU拡張だと思われます。
GCC(G++)で「-std=c++11」のオプションを付けてコンパイルできたら
それは標準規格です、できないと思いますが。



osakana

リンク

2014/12/6(Sat) 18:46:45|NO.66319

ふいに思いついたのでやってみました(本当に出来るとは思わなかった)
不便ですがこういうことも出来るみたいですね不便ですが
同じフォルダ上に個別に保存し主の方を実行してみてください。

// 主.hsp // 元になる定数 #const test 0 ; #define じゃダメみたい #include "従.hsp"

// 従.hsp mes test // 定数インクリメント #const test2 test + 1 #undef test #const test test2 #undef test2 #if test < 10 #include "従.hsp" #endif // 定数デクリメント #const test2 test - 1 #undef test #const test test2 #undef test2



osakana

リンク

2014/12/7(Sun) 15:52:15|NO.66336

少し確認不足でした今試してみたら
主.hsp の方は #define でも良いみたいですね。



ONION software Copyright 1997-2018(c) All rights reserved.