October 21, 2007memcpyによるクラスのコピー[Computer]
C++の話です。オリジナルのQueue、すなわちFIFO(First In First Out)といった方がわかりやすいでしょうか、を実装することになりました。基本的なアルゴリズムなので、車輪の再発明は極力避けるべきだ、というのが常識だと思いますが、STLがないDSP用のプログラムを書かなければならない為やむを得ずといったところです。実のところ、本人的にはこういう基礎アルゴリズムを実装するのは、勘を養うことにもなりますし結構楽しんでやってしまいました。 実装にあたって、当初はcharやintといった基本型程度しか使わないかなと思っていたので、FIFOへの書込み、読み出しはmemcpyを使って実装していました。ところが途中から汎用化欲がフツフツと沸き始め、ええぃ普通のクラスも管理できれば、いつかどこかで楽しい思いをできるに違いないと思えてきたのです。 そこで今回のお題なわけですが、果たして自分で作ったクラスのコピーをとるのはmemcpyでいいのでしょうか。答えを言ってしまうと、memcpyでは問題がおこる場合があります。実際に今回は2つの問題に遭遇しました。 まず第1のケースは、以下に示すコードのような、参照カウンタを利用してライトウェイトな実装になっている場合です。 class LightWeight{
private: struct storage_t { int ref; ///< 参照カウンタ int value; ///< 何か値 storage_t() : ref_count(0) {} }; storage_t *content; public: LightWeight() : content(new storage_t()) {} ///< コンストラクタ ~LightWeight(){ ///<デストラクタ if(content && ((--(content->ref)) <= 0)){ delete content; } } LightWeight(const LightWeight &obj){ ///< コピーコンストラクタ if(content = obj.content){(content->ref)++;} } LightWeight &operator=(const LightWeight &obj){ ///<代入演算子 if(this != &obj){ if(content && ((--(content->ref)) <= 0)){delete content;} if(content = obj.content){(content->ref)++;} } return *this; } int &content(){return (content ? (content->value) : *(int *)NULL);} }; このようなLightWeightクラスをコピーする場合は、代入演算子か、コピーコンストラクタによるコピーで参照カウンタの整合性を確保してやる必要があります。もしmemcpyで単純にコピーをすると参照カウンタが本来参照されている数よりも少なくなってしまい、Segmentation Faultが発生してしまいました。 遭遇した第2のケースですが、継承関係があり仮想関数が使用されている場合です。同じくコードで示します。 #include <iostream>
using namespace std; class Base{ memecpyと代入演算子(=)の役割が同じであるならば、(1)、(2)、(3)、いずれも同じ出力が得られるはずですが、実はそうなりません。(1)では"Base::hoge"が、(2)と(3)では"Sub::hoge"が出力されます。これは仮想関数を成り立たせる仕組みの仮想関数テーブル(詳細はGoogle先生『仮想関数テーブル』)がコピーされるかどうかの違いで、本来はコピーされるべきではない仮想関数テーブルまでもがmemcpyではコピーされてしまうためにおきた問題です。例で示したコードだとあまり深刻さが伝わらないですが、子クラスで定義されたメンバ変数にアクセスする仮想関数がある場合などはおかしなことが起きると思います。 他にもmemcpyを使うと問題がおこるケースがあると思いますので、結局のところ、実装したFIFOでは、memcpyを使うか、代入演算子を使うか、あるいはもっと他の方法を使うか、ファンクタで選べるようにしました。拙いコードfifo.hをおいておきます。 コメント
コメントする
|
スポンサード リンク
|