アカウント名:
パスワード:
この話が邪悪なのはコンパイル時に無警告なこと。普通は未使用変数があったくらいでも警告するのに、未実行で警告しないとか頭おかしい。これが正規動作で修正されないなら LLVM 捨てるのが正解。
オープンソースのプロジェクトなんだからさ、要望があったらissue作るなりMLでリクエストするなりしたら?
当然、要望は既に出てる。警告どころか、実行不可能な文があるならコンパイル・エラーで止めるのが正しい気がする。トラブルのわかっていて事前に対応しなかった開発者の見識が疑われる案件。
要望ってどれ?
開発者の見識が疑われるって誰か自分以外の偉い人が対応するのが当然てか?こういうこと書くやつの見識こそ疑われるよ
詳しい経緯聞いてからだろ。てか経緯教えろください
たとえばぬるぽに書き込むコードに置き換えてくれる方が親切ではあるかもしれないわな。
捨てるまではいかないが、検出できるのなら警告してくれるとありがたい
警告は無理なんじゃない? 他のコメントを見てるとC++だと、「constを外す」、「そこから読み込む」まではセーフらしいし、そういう正常な例まで警告を出すとうるさい。
read_or_write_hoge(0, buffer); // 1個目の引数が0ならバッファへの読み込みread_or_write_hoge(1, buffer); // 1個目の引数が1ならバッファの内容を書き出し
みたいなのがあったとして、1(書き出し)を指定したときは、bufferの内容は不変だと保証してるならconstな領域を渡しても無害なわけで。
これだと、そんなAPI設計するやつは窓から捨てろ、みたいな例になっちゃってるけど、まあ、究極の効率化とかを求めてると、何かしらそうせざるを得ないような場面も無いことはないんじゃないかな。知らんけど。あるいは、ヘボ開発者が作ったAPIに、受け取ったポインタの先に書き込まない関数なのに宣言にconstを付けてないものがある、とか。
関数内でbufferに書き込むかどうかをコンパイラに判断できないから、そもそも問題の最適化は行えない。
仮にread_or_write_hogeがbuilt-in関数で、関数のふるまい迄コンパイラが把握していたとしても第1引数がコンパイル時に確定できないなら、警告は出せないけど最適化もできない。第1引数が確定するならその値に応じて警告を出せるし最適化もできる。
正常な例でも紛らわしい書き方なんかで警告してくれるのは道具として当たり前に期待される動作でしょ
bool hoge(bool a, bool b, bool c){ return a || b && c;}
https://wandbox.org/permlink/h7gsXJ15nwkdH [wandbox.org]
コメントを見てると、"constな領域への書込み"と、const宣言付けた変数をキャストでcost外して書込むってのがごっちゃになっていると思う。
まあconst_castなんてした時点でこれから危ないことしますよ宣言で分かってやってるんだろうから警告しませんよという判断もあるかもしれない
obsoletedな機能みたいなもんじゃん。「const付けた領域への書き込み機能はいつか廃止の可能性があります」と(も読める内容が)最初から規格に書いてあったんだから。
#「臨時通路。工事の進捗次第で閉鎖します」と書いてある通路を日常的に使ってるローカル民が#「それを閉じられると困る。我々の生活が困っても良いのか」と街の開発を邪魔してるのを遠くから眺めてるのに似た気分
「臨時通路は今後予告なくピットになります。蓋は配置しません」
それは、「キャストしたからってコンパイル可能にはしないよ」という意味な気がする。
キャストを付けるっていうのは割と頻繁に行われ易いにも関わらず、プログラマは無謬だって前提になっちゃうからなぁ。キャストする重大さってあまり認識されていないのが問題なんじゃないかな。形式上の不一致を消すためのものはともかく、値が一意に定まらないものやアクセス違反になるものなど重大なものは警告は消えないでほしい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
無警告 (スコア:1)
この話が邪悪なのはコンパイル時に無警告なこと。
普通は未使用変数があったくらいでも警告するのに、未実行で警告しないとか頭おかしい。
これが正規動作で修正されないなら LLVM 捨てるのが正解。
Re: (スコア:0)
オープンソースのプロジェクトなんだからさ、
要望があったらissue作るなりMLでリクエストするなりしたら?
Re:無警告 (スコア:1)
当然、要望は既に出てる。
警告どころか、実行不可能な文があるならコンパイル・エラーで止めるのが正しい気がする。
トラブルのわかっていて事前に対応しなかった開発者の見識が疑われる案件。
Re: (スコア:0)
要望ってどれ?
Re: (スコア:0)
開発者の見識が疑われるって誰か自分以外の偉い人が対応するのが当然てか?
こういうこと書くやつの見識こそ疑われるよ
Re: (スコア:0)
詳しい経緯聞いてからだろ。てか経緯教えろください
Re: (スコア:0)
たとえばぬるぽに書き込むコードに置き換えてくれる方が親切ではあるかもしれないわな。
Re: (スコア:0)
捨てるまではいかないが、検出できるのなら警告してくれるとありがたい
Re: (スコア:0)
警告は無理なんじゃない? 他のコメントを見てるとC++だと、「constを外す」、「そこから読み込む」まではセーフらしいし、そういう正常な例まで警告を出すとうるさい。
read_or_write_hoge(0, buffer); // 1個目の引数が0ならバッファへの読み込み
read_or_write_hoge(1, buffer); // 1個目の引数が1ならバッファの内容を書き出し
みたいなのがあったとして、1(書き出し)を指定したときは、bufferの内容は不変だと保証してるならconstな領域を渡しても無害なわけで。
これだと、そんなAPI設計するやつは窓から捨てろ、みたいな例になっちゃってるけど、まあ、究極の効率化とかを求めてると、何かしらそうせざるを得ないような場面も無いことはないんじゃないかな。知らんけど。あるいは、ヘボ開発者が作ったAPIに、受け取ったポインタの先に書き込まない関数なのに宣言にconstを付けてないものがある、とか。
Re: (スコア:0)
関数内でbufferに書き込むかどうかをコンパイラに判断できないから、そもそも問題の最適化は行えない。
仮にread_or_write_hogeがbuilt-in関数で、関数のふるまい迄コンパイラが把握していたとしても
第1引数がコンパイル時に確定できないなら、警告は出せないけど最適化もできない。
第1引数が確定するならその値に応じて警告を出せるし最適化もできる。
Re: (スコア:0)
警告は無理なんじゃない? 他のコメントを見てるとC++だと、「constを外す」、「そこから読み込む」まではセーフらしいし、そういう正常な例まで警告を出すとうるさい。
正常な例でも紛らわしい書き方なんかで警告してくれるのは道具として当たり前に期待される動作でしょ
bool hoge(bool a, bool b, bool c)
{
return a || b && c;
}
https://wandbox.org/permlink/h7gsXJ15nwkdH [wandbox.org]
Re: (スコア:0)
コメントを見てると、"constな領域への書込み"と、const宣言付けた変数をキャストでcost外して書込むってのがごっちゃになっていると思う。
Re: (スコア:0)
まあconst_castなんてした時点でこれから危ないことしますよ宣言で
分かってやってるんだろうから警告しませんよという判断もあるかもしれない
Re: (スコア:0)
obsoletedな機能みたいなもんじゃん。「const付けた領域への書き込み機能はいつか廃止の可能性があります」と(も読める内容が)最初から規格に書いてあったんだから。
#「臨時通路。工事の進捗次第で閉鎖します」と書いてある通路を日常的に使ってるローカル民が
#「それを閉じられると困る。我々の生活が困っても良いのか」と街の開発を邪魔してるのを遠くから眺めてるのに似た気分
Re: (スコア:0)
「臨時通路は今後予告なくピットになります。蓋は配置しません」
Re: (スコア:0)
それは、「キャストしたからってコンパイル可能にはしないよ」という意味な気がする。
Re: (スコア:0)
キャストを付けるっていうのは割と頻繁に行われ易いにも関わらず、プログラマは無謬だって前提になっちゃうからなぁ。
キャストする重大さってあまり認識されていないのが問題なんじゃないかな。
形式上の不一致を消すためのものはともかく、値が一意に定まらないものやアクセス違反になるものなど重大なものは警告は消えないでほしい。