問題タブ [code-elimination]

javacのコード削除機能に関する情報を見つけるのに苦労しています。

次のようなものがある場合、ifステートメントは削除されると読みました。

しかし、たとえば次のようにするとどうでしょうか。

またはこれ：

javacプログラムを分析してすべてのデッド コードを見つけることは非常に困難/不可能であるため (おそらく停止問題に似ています)、認識して削除する明確に定義された構造 (上記の最初の例のように) はわずかしかないと思います。確実に。これらの構造の包括的なリストはありますか?

コードベースに未使用の機能がいくつかありますが、特定するのは困難です。この 1 年でコードは進化し、その問題空間と考えられる解決策を探りました。私がしなければならないことは、その未使用のコードを見つけて、それを取り除くことです。エクスポート可能な名前で問題を解決してくれると嬉しいです. GHC には、エクスポートされていない未使用コードに関する警告があります. このタスクに固有のツールは興味深いものです。

しかし、総合的な相互参照ツールに興味があります。このようなツールで未使用のコードを見つけることができます。何年も前に C とアセンブラーで作業していたとき、優れた xref が非常に便利なツールであり、さまざまな目的に役立つことに気付きました。

私はグーグルでどこにも行きません。どうやら Haskell では、相互参照の支配的な意味は、文芸的なプログラミング内にあります。多分何かが役に立つかもしれませんが。

hereで説明されているように、javac およびその他の Java コンパイラはif、条件が「定数式」であるステートメントのコード削除機能を提供する場合があります。

私のコードが別のパッケージで定義された他の定数式に依存する定数式を使用している場合、これはどのような影響を受けますか?

たとえば、指定されたそれぞれのパッケージに次のクラスがあるとします。

と

明らかに、foo-package が実行時に外部の jar ファイルからロードされた場合、コンパイラはそれFoo.CONDITIONが false になると技術的に想定することはできずtrue、-statement のif-branch を削除すべきではありません。

一方、FooとBarが実際に同じパッケージにある場合、true-branch は確実に削除する必要があります (コンパイラがコードの削除をサポートしている場合)。

この質問をどのように表現するのが最適かはよくわかりませんが、 の定数式が の定数と見なされるには、どれだけ「近い」Foo必要がありますか? それらは同じファイルにある必要がありますか？同じパッケージ？同じjarファイル？それともまったく問題ではありませんか (つまり、コンパイラは常に定数と見なし、コンパイル時にビルドパスで見つかった値を使用します)?BarFooBarFoo.CONDITION

goto ですべてを作成するのは簡単ですが (f.ex. IL で証明されているように)、 Java でサポートされているすべてのものを使用して、高レベルの式とステートメントを含むすべてのgoto ステートメントを削除することも可能かどうか疑問に思っていました。

または、必要に応じて: 私が探しているのは、goto の作成方法に関係なく、常に機能する「書き換えルール」です。

それは主に理論的な質問として、純粋に興味として意図されています。良い/悪い習慣としてではありません。

私が考えた明らかな解決策は、次のようなものを使用することです。

これはおそらく機能し、私の「正式な」質問には合っていますが、私の解決策は少し好きではありません。1つには、それは非常に醜く、2つには、基本的にgotoを、gotoとまったく同じことを行うスイッチにラップします。

それで、より良い解決策はありますか？

更新 1

多くの人が質問が「広すぎる」と考えているように見えるので、もう少し詳しく説明します... 私が Java に言及した理由は、Java には「goto」ステートメントがないためです。私の趣味のプロジェクトの 1 つとして、私は C# コードを Java に変換しようとしていましたが、これは非常に困難であることがわかっています (Java のこの制限が原因の 1 つです)。

それは私に考えさせました。あなたがf.exを持っている場合 Open addressing での「remove」メソッドの実装 ( http://en.wikipedia.org/wiki/Open_addressing - 注 1 を参照)。例外的な場合に「goto」があると非常に便利ですが、この特定のケースでは「状態」変数を導入することで書き直すことができます。これは 1 つの例にすぎないことに注意してください。継続用のコード ジェネレーターを実装しました。これらのコード ジェネレーターは、逆コンパイルしようとすると大量の goto を生成します。

また、この問題の書き直しが常に「goto」ステートメントを排除するかどうか、およびすべての場合に許可されるかどうかもわかりません。私は正式な「証拠」を探しているわけではありませんが、この問題で排除が可能であるといういくつかの証拠は素晴らしいでしょう.

したがって、「広さ」については、「答えが多すぎる」または「goto を書き直す方法がたくさんある」と考えるすべての人々に、アルゴリズムまたは一般的なケースを書き直すためのアプローチを提供してください。これまでは私が投稿したものです。