CppInterOpのC++相互運用のアプローチは完全にジャンクだと思う（ダジャレじゃないよ）。このアプローチは、C++を文字列として扱って、それを解析・解釈してABI準拠の呼び出しを生成するんだ。だから、これは本当にジャンクに聞こえるね。私の質問は、ジャンクに聞こえるだけじゃなくて、何か問題があるの？遅いとか信頼性がないとか？

こんにちは！ここにいるよ、受け入れる準備もできてる。Clangが実際に私のユースケースをサポートできればいいんだけど、残念ながらClangはスタンドアロンのAOTコンパイル用に設計されていて、他のIR生成メカニズムと絡むことは考慮されてないんだ。それに、Clangは一部のエラーを優雅に処理できず、悪い状態に陥ることがある。最近の四半期で、jankのCppInterOpのフォークをかなり成長させたよ。変更リストはここにあるよ： https://gist.github.com/jeaye/f6517e52f1b2331d294caed70119f1... これを全てアップストリームに持っていきたいけど、今は優先度が高くないから結構大変なんだ。CppInterOpの内部を見てきた経験から言うと、一番大きな問題はC++のコード生成じゃないと思う。基本的に、どんなコード生成も文字列を構築する形になるんだ。君がリンクしたCppInterOpの部分はC++関数を構築してるけど、ロバスト性の観点から言うと、実際に何が問題なの？文字列は任意のユーザー入力に基づいて生成されるんじゃなくて、ClangのQualTypesとDeclsに基づいて生成されるんだ。つまり、実際にそこにたどり着くには有効なClangの値が必要なんだよ。ABIの状況が完全に混乱していて、jankがすでにClangのJIT C++コンパイラを使っていることを考えると、これは非常に実行可能な解決策だと思う。ただ、ロバスト性の観点では、Clangのエラーハンドリングや優雅さの欠如、こういうユースケースに対するツールの貧弱さに戻るんだ。私の経験から言うと、それがロバスト性の問題を引き起こす原因になると思う。私の返答を受け入れられないとか防御的だと思わないでほしい。ディスカッションを本当に感謝してるし、もし私が何か間違ったことを言ってるなら、もっと説明してくれたら嬉しい。代替案については、君がリンクした https://github.com/Mr-Anyone/abi は3ヶ月前のもので、星が0（つまりユーザーも0、戦闘テストの年数も0だと思う）だね。それに、君がリンクした https://discourse.llvm.org/t/llvm-introduce-an-abi-lowering-... も素晴らしいと思うけど、_もし/いつそれが利用可能になったら_って感じだね。だから、すべての選択肢の中で、率直に聞くけど、今日存在する本当に_より良い_選択肢はあるの？CppInterOpはjankの実装の詳細なんだ。もしC++の文字列生成をもっとIR生成とポータブルなABIメカニズムに置き換えられ、Clangが私のテンプレート特殊化が正しいインスタンス化を得るためにC++の文字列に依存しなくて済むような十分なライブラリを提供できるなら、私は間違いなくCppInterOpを置き換えることにオープンだよ。見た限りでは、まだそこには至っていないね。

これについてずっと考えてたんだけど、jankが再帰的な頭字語だってどういうことなのか全くわからない。君が見えてるものは何なの？

ランタイムにLLVMを埋め込んでるわけじゃない - clangを埋め込んでるんだ。私の下のコメントを見れば、LLVMは現在十分じゃないってわかるよ。 > [C++]は名前のマングリングのせいでダイナミックFFIをターゲットにするのが本当に面倒なんだ。名前のマングリングはC++ FFIの中で一番簡単な部分で、難しいのはABIの残りの部分なんだ。興味がある人はここから始めてみてね https://github.com/rust-lang/rust-bindgen/issues/778

カーマックはトリニティ/クエイク3エンジンでほぼ同じことをやったよね。確かLCCかtccだったかな、個人でも完全に理解できるCコンパイラの一つだよ。彼はCをsyscall用のいくつかのビルトインを使ってコンパイルして、自分のスタックマシンに変換したんだ。でも、ネイティブDLL用のターゲットもあったから、安全なsyscallインターフェースは同じだけど、セグメンテーションフォルトが起きる可能性もあるから、信頼しなきゃいけない。こんな一つのプログラムの中で（エリートなレジェンドたちの高概念FAANG C++よりもまだ読みやすい、本当にユニークなもの）、これが一番劇的な革新じゃなかったなんて、すごいことだよ。実際には、これがそのプログラムの中で三番目に劇的な革命だったんだ。こういうのに興味があるなら、病欠して一日中プランファイルを読んでみて。ゾクゾクするよ。

名前のマングリングに関する標準化がない、またはコンパイル時に名前をマングルしたりデマングルする方法がない。多くのことと同じように、これはC++の問題じゃない。標準はあって、ほとんどのターゲットがそれを使ってる…で、マイクロソフトがやってることがある。後者に対処しなきゃならないときだけ問題が出てくる。今、標準は進化するし、これによって異なるシステムライブラリやツールが何が受け入れられるか、正しいかについて異なる見解を持つ余地ができる（I...EとJ...Eのエラーを解決しようとしたときの悪夢は今でも忘れられない）…でも、すべての機能は存在していて、最前線にいなければうまく動くよ（幸いなことに、C++11は本当に必要な部分を提供してくれたし、それ以降はただの「あったらいいな」って感じ）。

名前のマングリングに関する標準化がない 名前のマングリングを標準化する意味がわからない。標準があると仮定しよう、そうしたら今度は標準ライブラリにあるすべてのクラスのメモリレイアウトを標準化しなきゃならない。それがなければ、リンク時に失敗する代わりに、仮想のプログラムは実行中に醜い形で壊れることになる。例えば、互いに呼び出し合う二つの関数がstd::stringの長さがメモリのどこにあるかについて異なる意見を持っていたら。

C++のポータビリティやABI、標準については理解してるよ。だけど、jankがLLVM以外の何を使うと思ってるのかはわからないな。ClojureはJVMを使ってるし、jankはLLVMを使ってる。JITランタイムやjankのコンパイラバックエンド（IR最適化やターゲットコード生成のため）を処理するために_何か_が必要になると思う。LLVMじゃなければ、jankは別の何かを組み込むことになる。これら二つを自分で構築しなきゃならないとなると、すでに巨大なプロジェクトが手に負えないものになってしまうよ。

コンパイル時に名前をデマングルするのは、標準化されてるわけじゃないけど、今はGCCやClangでできるよ。__PRETTY_FUNCTION__をうまく使えばね。

Shedskin言語はC++との統合が素晴らしいよ。

もちろんjankはすでにC++のサポートを得てるけど、もしD言語のサポートがあったとしたら、もっと簡単だったり実現可能だったりしたのかな？

参照カウントから始めたけど、Clojureのプログラムが出すゴミの量が多すぎて、GCを使わないと全体が遅くなっちゃうんだ。jankのGCは今後変わる予定で、オプショナルなアファイン型をサポートしてほしいけど、Clojureのベースは多分ずっとガベージコレクションされるだろうね。

記事の最初の部分だよ - 「cpp/newとcpp/deleteを使って手動メモリ管理を実装した。これはmallocではなく、jankのGCアロケータ（現在はbdwgc）を使っているから、cpp/deleteを使う必要は基本的にない。ただし、cpp/deleteを使うと、メモリの収集が早くてより決定的になることがある。実装にはデストラクタのためのbdwgcの完全サポートもあるから、手動削除と自動収集の両方が非自明なデストラクタをトリガーするよ。」

GCはこれの中で一番難しい部分じゃないよ。2014年にはC++のJITコンパイルに使える技術がなかったし、ネイティブコードのJITコンパイルに関してもほとんど技術がなかったからね。

記事によると、ガベージコレクションは常に行われるけど、deleteを呼び出すと、ガベージコレクターがもっと積極的に掃除をするようになるんだって。