アカウント名:
パスワード:
CLRで統合する利点としては以下のような感じになるでしょうか。
相互コンバーターということで逆もあってもいいと思いますが、実際一度高級言語からバイトコードまで落としてしまうと逆コンパイルして可読性のあるコードを保つのは難しいでしょうね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
FireBird (スコア:1, 参考になる)
MicroSoft の目標は .PDB デバッグ情報をヒントにした、Native <-> Managed 相互コンバーターの作成です。
Managed コードは、それ自体が中間言語ですから十分な情報がついていますが
一般 Native コードにはそれがない。力業で逆アセンブルしても完全には内容が把握できない。
だが .PDB に十分な情報が入っていれば何とかなる。
ここで .PDB 付き Native バイナリを生成した元言語は必要ないことに注意。
アセンブラだろうが C++ だろうが、.PDB 付き .EXE/.DLL から C# ソースを作成してしまうことができるわけ。
いっ
statical analyzer for all platform(Re:FireBird) (スコア:2)
CLRで統合する利点としては以下のような感じになるでしょうか。
言語毎にstatical analyzer(バッファオーバーフロー
が発生しないかどうか解析するツールね, 例えばllvm-GCC)
を作らなくてもCLR managed codeに対するanalyzer
だけ作れば済む。
managed codeのある命令に該当する元のソースコードの
行数なんかもわかる。
JavaバイトコードだとJavaの世界から外に出れないという難点がありま
す。CLRならOSのほとんどの部分(もしかするとドライバも)
を記述できる。
相互コンバーターということで逆もあってもいいと思いますが、
実際一度高級言語からバイトコードまで落としてしまうと
逆コンパイルして可読性のあるコードを保つのは難しいでしょうね。
Re: (スコア:0)
可読性は必要ないのでしょう。