オブジェクトをC++に渡すときに、Rのガベージコレクションに何らかの問題があります。C/C++にオブジェクトを渡すときにRガベージコレクションを禁止する方法は?
我々は、以下のシナリオがあります。私たちはRで匿名関数を作成し、(.Call()
介して)C++コードに渡す
- を
- C++コードは、後で使用するためにRの関数オブジェクトを格納する(AS
SEXP
タイプ)以降に - を返し、他のいくつかのC++コードを呼び出すには、ステップ間
R_tryEval()
を使用してRの関数オブジェクト前記2と3の場合、R関数オブジェクトはRによってガベージコレクションされているように見えます。これは、R_tryEval()
が有効なR関数オブジェクトを表していないものを実行しようとするため、クラッシュします。それは公正だ、我々は関数オブジェクトが使用中であることをRを伝えるために何もしていないよう...念頭に置いて
:
- はC++コードからの方法がある、とR関数オブジェクトを使用中であるとマークする(gcを取得しないようにする)?
- 、あるいはC++コード内でR関数オブジェクトを複製し、
R_tryEval()
を呼び出した後でそれを手動で処分する安全な方法はありますか?
(これらは同じ範囲内でバランスを取ることになっているので、私の知る限り理解し、PROTECT()
/UNPROTECT()
マクロがここにオプションではありません。のように関数が最初に渡されたとき、私たちはPROTECT()
を呼び出すことはできませんその後、C++、それが実行された後、後UNPROTECT()
を呼び出す。)
どのようにオブジェクトを保存していますか?私は(実際には考えずに)外部ポインタを使用することができると思います。もしそうでなければ、Rのどこかにそれをそのまま残しておき、必要に応じてfindVarを呼び出すことができます。 –
@ジェフ - ありがとう。あなたが説明したことは、私たちが考案した回避策に非常に近いものです。関数オブジェクトをR側のリストに追加してから、C++に渡します。 (私たちはこれをやっていて満足しています...ちょうど私たちがdo-not-gcとしてオブジェクトにフラグを立てるために呼び出さなければならない "公式の"関数がないことを確認したかっただけです) – qethanm
ハック行って、これはケーキを取るかもしれません。あなたがRcppを使わなくても、適切な解決法についてはMartinの答えを見てください。 –