問題タブ [raii]

オブジェクトが破壊されたときに何が起こるかを制御できないのは設計上のものであることはわかっています。また、一部のクラス メソッドをファイナライザーとして定義することも認識しています。

しかし、C++ の RAII (リソースはコンストラクタで初期化され、デストラクタで閉じられる) の Ruby イディオムですか? エラーや例外が発生した場合でも、オブジェクト内で使用されるリソースをどのように管理しますか?

確実に動作するようにする：

ただし、クラスのユーザーは、open メソッドを呼び出す必要があるたびに、 begin-rescue-ensure チャチャ全体を実行することを覚えておく必要があります。

たとえば、次のクラスがあります。

例外が他のクラスによって引き起こされ、スクリプトが終了した場合、resource_handle は閉じられません。

それとも、私がまだこれをC++のようにやっているという問題ですか？

私は現在 CUDA を使い始めており、C API に少しがっかりしていることを認めなければなりません。C を選択した理由は理解できますが、代わりに言語が C++ に基づいていた場合、デバイス メモリの割り当て (経由cudaMalloc) など、いくつかの側面がより単純になったはずです。

operator new私の計画は、オーバーロードされた配置newと RAII (2 つの選択肢)を使用して、これを自分で行うことでした。今まで気付かなかった注意点があるのではないかと思っています。コードは機能しているように見えますが、メモリ リークの可能性についてまだ疑問に思っています。

RAIIコードの使用法は次のようになります。

おそらく、このコンテキストではクラスがやり過ぎなので（特に、cudaMemcpyRAIIをカプセル化するだけのクラスを使用する必要があるため）、他のアプローチは配置newになります：

ここでは、cudaDevice単にオーバーロードをトリガーするタグとして機能します。ただし、通常の配置でnewはこれは配置を示しているため、構文が奇妙に一貫しており、おそらくクラスを使用するよりも好ましいとさえ思います。

あらゆる種類の批判をいただければ幸いです。この方向の何かがCUDAの次のバージョンで計画されているかどうか誰かがおそらく知っていますか（私が聞いたように、それが意味するものは何でも、C++サポートが改善されます）。

したがって、私の質問は実際には 3 つあります。

1. プレースメントのnewオーバーロードは意味的に正しいですか? それはメモリをリークしますか？
2. この一般的な方向に進む将来の CUDA 開発に関する情報を誰かが持っていますか (それに直面しましょう: C++ s*ck の C インターフェイス)?
3. これを一貫した方法でさらに進めるにはどうすればよいですか (他にも考慮すべき API があります。たとえば、デバイス メモリだけでなく、定数メモリ ストアとテクスチャ メモリもあります)。

ここで採用されているシングルトンについて: はい、その欠点は認識しています。ただし、これらはこのコンテキストには関係ありません。ここで必要だったのは、コピーできない小さなタイプのタグだけでした。他のすべて (つまり、マルチスレッドの考慮事項、初期化の時間) は適用されません。

私は自分のコードでboost::scoped_ptrを多用していますが、それは素晴らしいことですが、現在、どこでもshared_ptrを使用するソフトウェアを使用しており、何かが足りないのではないかと思っています。

Shared_ptrは、異なるスレッドが同じデータにアクセスする予定であり、スレッドが終了する順序がわからない場合にのみ役立ちます（shared_ptrを使用すると、最後のスレッドが終了するまでオブジェクトが存在することが保証されます）。

他のユースケースはありますか？

純粋な C でRAIIを実装することは可能ですか?

正気の方法では不可能だと思いますが、ある種の汚いトリックを使用して可能である可能性があります。標準free関数をオーバーロードするか、スタック上の戻りアドレスを上書きして、関数が戻ったときに何らかの方法でリソースを解放する他の関数を呼び出すことを思い浮かべますか? それとも、setjmp/longjmp のトリックでしょうか。

これは純粋に学術的な関心事であり、私は実際にそのような移植性のないクレイジーなコードを書くつもりはありませんが、それが可能かどうか疑問に思っています.

Bjarne Stroustrup は、彼のC++ Style and Technique FAQに書いています。

C++ は、ほとんど常により優れた代替手段をサポートしているため、「リソース取得は初期化」手法 (TC++PL3 セクション 14.4) です。基本的な考え方は、ローカル オブジェクトのデストラクタがリソースを解放するように、ローカル オブジェクトによってリソースを表すことです。そうすれば、プログラマーはリソースの解放を忘れることはありません。例えば：

システムでは、リソースごとに「リソース ハンドル」クラスが必要です。ただし、リソースを取得するたびに「finally」句を付ける必要はありません。実際のシステムでは、リソースの種類よりもはるかに多くのリソースの取得が行われるため、「リソースの取得は初期化です」という手法は、「最終的に」構成を使用するよりもコードが少なくて済みます。

Bjarne は、「常により良い」ではなく、「ほぼ常により良い」と書いていることに注意してください。さて、私の質問ですがfinally、C++ で代替コンストラクト (RAII) を使用するよりもコンストラクトの方が優れているのはどのような状況でしょうか?

C++ で実際に使用する場合、 RAIIとは何ですか?

過去 2 年間、プロジェクトでスマート ポインター (正確には boost::shared_ptr) を広く使用してきました。私はそれらの利点を理解し、高く評価しており、一般的にそれらをとても気に入っています. しかし、それらを使用すればするほど、プログラミング言語で気に入っているように見えるメモリ管理と RAII に関する C++ の決定論的な動作が恋しくなります。スマート ポインターは、メモリ管理のプロセスを簡素化し、とりわけ自動ガベージ コレクションを提供しますが、問題は、一般的に自動ガベージ コレクションを使用し、スマート ポインターを具体的に使用すると、初期化 (非) 化の順序である程度の不確定性が導入されることです。この不確定性は、プログラマーからコントロールを奪い、最近気付いたように、API の設計と開発の仕事をします。

さらに詳しく説明すると、現在 API を開発しています。この API の一部では、特定のオブジェクトを他のオブジェクトの前に初期化または破棄する必要があります。別の言い方をすれば、初期化 (非) 化の順序が重要な場合があります。簡単な例として、System というクラスがあるとします。システムは、いくつかの基本的な機能 (この例ではロギング) を提供し、スマート ポインターを介して多数のサブシステムを保持します。

すでにおわかりのように、サブシステムはシステムのコンテキストでのみ意味があります。しかし、そのような設計のサブシステムは、その親システムよりも簡単に存続できます。

サブシステムを保持するために生のポインターを使用していた場合、システムがダウンしたときにサブシステムを破棄していたでしょう。もちろん、pSomeSubsystem はダングリング ポインターになります。

クライアント プログラマを保護するのは API 設計者の仕事ではありませんが、API を正しく使いやすく、間違って使いにくくすることは良い考えです。だから私はあなたたちに尋ねています。どう思いますか？この問題をどのように緩和すればよいですか? そのようなシステムをどのように設計しますか?

前もって感謝します、ジョシュ

コンストラクタ/デストラクタ以外で何もしないクラスがいくつかあります。これが例です

今後の可読性が少し気になります。コードで実際に使用されることのない変数 (「ビジー」) を使用して、ここで「トリッキー」すぎますか? いくつかの静的分析ツールは、それらが削除されることを示唆する可能性がありますか?それとも、このイディオムは心配する必要がないほど一般的ですか?

私が Java を扱ってから少なくとも 5 年は経ちますが、その頃は、クリーンアップが必要なオブジェクト (ソケット、DB ハンドルなど) を割り当てたいときはいつでも、finallyブロックを追加してクリーンアップ メソッドを呼び出すことを覚えていなければなりませんでした。そこの。

対照的に、C++ (または Perl などのオブジェクトの有効期間が決定論的である他の言語) では、クラスの実装者は、そのクラスのオブジェクトがスコープ外になるたびにクリーンアップを実行するデストラクタ関数を定義します。このアプローチの利点は、オブジェクトのユーザーがオブジェクトのクリーンアップを忘れないことです。例外がスローされた場合でも、デストラクタが自動的に呼び出されます。このアプローチは、RAII のかなりひどい名前 (「リソースの取得は初期化」) で行われます。

「RAII の方法」で物事を行うことで、リソースの割り当て解除が発生するかどうか、いつ発生するかを心配する必要がないという点で、多くの精神的オーバーヘッドを節約できたというのが私の経験です。私たちは中規模のプロジェクトに Java を使用することを検討していますが、最後に Java を調べてから言語に追加された多くの新機能の中に、ある種の決定論的破壊があるのではないかと考えています。（「JavaにはRAIIがない」という私の不満がこのスレッドで非難されたことを願っていますが、これまでのところ、グーグルで詳細を見つけることができませんでした。）

したがって、誰かがJavaでこれを行う方法についての入門資料を教えてくれれば、それは素晴らしいことです!