「コンパイラ・スクリプトエンジン」相談室7
56 ：デフォルトの名無しさん：
MinGW上でBison++1.21.8＆Flex-2.5.4a使ってるんだけど
C++用に生成させた複数のパーサ＆レクサ（って言うのか）を使ってるときに
なぜかあるパーサが違うパーサ用のレクサを使ってしまうという現象に悩まされています。
同じ目にあったことある人いる？
ちなみにflexのソースには%option prefix=hogehoeを指定しています。
nmコマンドでオブジェクトを見るとちゃんと別々のレクサが生成されているようだけども…。
C++用に生成させた複数のパーサ＆レクサ（って言うのか）を使ってるときに
なぜかあるパーサが違うパーサ用のレクサを使ってしまうという現象に悩まされています。
同じ目にあったことある人いる？
ちなみにflexのソースには%option prefix=hogehoeを指定しています。
nmコマンドでオブジェクトを見るとちゃんと別々のレクサが生成されているようだけども…。
|
|
|
57 ：デフォルトの名無しさん：2005/10/19(水) 21:50:53
>>53
Lisper
Lisper
58 ：デフォルトの名無しさん：2005/10/19(水) 22:34:15
59 ：デフォルトの名無しさん：2005/10/20(木) 00:14:51
やっぱり最初はLISP作ることにします。
ありがとうございました。
ありがとうございました。
60 ：デフォルトの名無しさん：2005/10/20(木) 19:13:43
やっぱり最後はRuby作ることにします。
ありがとうございました。
ありがとうございました。
61 ：デフォルトの名無しさん：2005/10/21(金) 00:42:07
LLVM, SUIF, Trimaran, Zephyr, COINS ...
といろいろありますが、それぞれの向き／不向きとか使いやすさとか実際に使っている人が
いたらいろいろ情報キボンヌ。
といろいろありますが、それぞれの向き／不向きとか使いやすさとか実際に使っている人が
いたらいろいろ情報キボンヌ。
>>56は悩ましい1週間のデバッグの末ようやく解決した。
両方のパーサの*_y.hがincludeされてるソースが存在した。
両方のマクロ定義とinline関数定義が干渉したらしい。
オリジナルを書いたフランス人曰く
「Linuxでは動いているからMinGWのリンカのせいではないか？」
などと言っていたが、むしろLinux上で無事動いてたのがむしろラッキー？
という感じの立派なバグだったようだ。
両方のパーサの*_y.hがincludeされてるソースが存在した。
両方のマクロ定義とinline関数定義が干渉したらしい。
オリジナルを書いたフランス人曰く
「Linuxでは動いているからMinGWのリンカのせいではないか？」
などと言っていたが、むしろLinux上で無事動いてたのがむしろラッキー？
という感じの立派なバグだったようだ。
63 ：デフォルトの名無しさん：2005/10/21(金) 05:16:44
64 ：デフォルトの名無しさん：2005/10/21(金) 07:02:42
>>61
情報はあるが、「キボンヌ」とか言ってる奴に答える気はしない。
情報はあるが、「キボンヌ」とか言ってる奴に答える気はしない。
>>63
綴りも全然違うのでそれはない。
単純に.hファイルのインクルードの連鎖の結果で2組のパーサ＆レクサの定義を含む.hファイル2つが
一個のファイルにインクルードされて利用された結果、マクロ定義が衝突して、
（FlexにC++コードを生成させたときのマクロの利用方法は少々トリッキーなので）
同じであるべきinlin関数についてコンパイル単位ごとに複数の異なる版
（正しい版と別のパーサ用のレクサにすり替わった版）が生じたことによるもの。
Linux版で動いていたのは複数の異なる版を持つinline関数という
規格上未定義である状況に対するコンパイラの挙動の違いで偶然正しく動いていただけ。
綴りも全然違うのでそれはない。
単純に.hファイルのインクルードの連鎖の結果で2組のパーサ＆レクサの定義を含む.hファイル2つが
一個のファイルにインクルードされて利用された結果、マクロ定義が衝突して、
（FlexにC++コードを生成させたときのマクロの利用方法は少々トリッキーなので）
同じであるべきinlin関数についてコンパイル単位ごとに複数の異なる版
（正しい版と別のパーサ用のレクサにすり替わった版）が生じたことによるもの。
Linux版で動いていたのは複数の異なる版を持つinline関数という
規格上未定義である状況に対するコンパイラの挙動の違いで偶然正しく動いていただけ。
>>63
あ、でも移植作業初期にはそういうトラブルもあったですよ。
MinGW環境からLinuxファイルサーバにsamba経由でアクセスしてるときに
同一ディレクトリ内に大文字小文字違い以外全く同一のファイル名のファイルがあって。
（ソースにそういう紛らわしい名をつけるのもどうかとは思うがｗ）
>>61
実は、今回の移植作業で現在開発中のコンパイラの壊れ物っぷりに
つくづく懲りたのでコンパイラ・フレームワークを使って
本格的に書き直す計画を立てている。
で、C++で書かれているSUIFという意見もあったが
Javaで書かれているCOINSを使おうと思っている。
Javaならクダンのフランス人が好きなGCも動的ロードも言語が標準で持ってるし、
SAXパーサもJavaの方が本家だし、
Unitテストやリファクタリングをサポートする開発環境Eclipseもあるし、
Rubyとも多分縁が切れるし、移植に悩まなくて済みそうだし、
何より今の壊れ物C++＆Rubyコードがそのまま持ち込まれる可能性が低いｗ
あ、でも移植作業初期にはそういうトラブルもあったですよ。
MinGW環境からLinuxファイルサーバにsamba経由でアクセスしてるときに
同一ディレクトリ内に大文字小文字違い以外全く同一のファイル名のファイルがあって。
（ソースにそういう紛らわしい名をつけるのもどうかとは思うがｗ）
>>61
実は、今回の移植作業で現在開発中のコンパイラの壊れ物っぷりに
つくづく懲りたのでコンパイラ・フレームワークを使って
本格的に書き直す計画を立てている。
で、C++で書かれているSUIFという意見もあったが
Javaで書かれているCOINSを使おうと思っている。
Javaならクダンのフランス人が好きなGCも動的ロードも言語が標準で持ってるし、
SAXパーサもJavaの方が本家だし、
Unitテストやリファクタリングをサポートする開発環境Eclipseもあるし、
Rubyとも多分縁が切れるし、移植に悩まなくて済みそうだし、
何より今の壊れ物C++＆Rubyコードがそのまま持ち込まれる可能性が低いｗ