問題タブ [pure-virtual]

テンプレートのダックタイピングと純粋な仮想基本クラスの継承のどちらかを選択するためのガイドラインはどれですか？例：

前方宣言と仮想関数の使用に問題があります。コンパイル中に次のエラー メッセージが表示されました。

コンパイラは、これらの関数はまだ純粋な仮想関数であると言っていましたが、私はそれらを適切に宣言および定義しました。何が問題なのかわからない。

これが私のソースコードです。

ありがとうございました。

一般的には仮想だけで十分だと思います。

派生クラスに独自のデストラクタを強制的に実装する以外に、純粋な仮想にする理由は他にありますか? つまり、クラスのコンストラクターに何かを割り当てる場合は、クラスが派生しているかどうかにかかわらず、独自のデストラクタを実装する必要があります。

私がすでに知っているように、答えとしてはカウントされません。クラスの抽象化が必要で、純粋な仮想関数がない場合は、デストラクタに任せてください。

もう少し使い道は？

継承に基づいて TCP サーバー モデルを作成しようとしましたが、さまざまな成功を収めています。これらのサーバーは、これらのサーバーのシャットダウンとその他の単純なメンテナンス機能をタスクとするシングルトンによって管理されます。

TCPDaemon クラスの Stop() 関数は純粋仮想関数です。私の問題は、Shutdown() 関数が呼び出されたときに、派生クラスのバージョンではなく、この純粋な仮想を呼び出そうとしていることです。どうすれば正しいことを強制できますか？

前もって感謝します

[編集] 申し訳ありませんが、以前に TCPDaemon コードを含めていませんでした。これは TCPSocket クラスから派生しています (これは 100% 動作することを確認しており、かなり一目瞭然です)。ここにあります：

サンプルの派生サーバーとその作成方法を次に示します。

[編集+1] 問題はこれに要約されると思います(私は簡単に間違っている可能性があります): 私は、純粋な仮想/抽象関数 Stop() を持つ基本クラス TCPDaemon の std::map を持っています。マップ内のエントリの 1 つを介して Stop() を呼び出すと、オーバーライド関数 EchoServer::Stop() ではなく、TCPDaemon::Stop() を呼び出そうとしているようです。これが問題でしょうか？もしそうなら、どうすれば解決できますか？

重複の可能性:
C++ 仮想/純粋仮想の説明
c++ での仮想関数のインスタンス化の違いは何ですか
? 純粋仮想関数が 0 で初期化されるのはなぜですか?

これは、誰かが私にくれたクラス宣言のメソッドです。そして、「..=0」が何を意味するのかわかりません。それは何ですか？

既存の C++ プロジェクトを拡張しています。2 つの親クラスから派生した基本クラスがあります。親の 1 つに純粋な仮想機能があります。その純粋仮想関数を、もう一方の親に実装された関数によって定義したいと考えています。

したがって、親の純粋仮想関数を定義する基本クラスの義務を別の親が満たしてほしいと思います。私は 2 つのアプローチを試しましたが、どちらもコンパイラ エラーにつながりました。
何か案は？

これは、私の最初のアイデアを示す C++ プログラムです。コンパイラがbase2の の定義を使用することを期待していvfunc()ます。

derivedコンパイラは、これがまだ抽象クラスであると報告します。

これが私の2回目の試みです：

私は実際にこれでうまくいくと思っていましたが、代わりにリンカが私が理解できない一連の vtable エラーを出しています: ( Mac OS 10.6, gcc 4.2.1 )

基本クラスの純粋仮想関数を置き換えるメソッドを宣言する必要がありますか？もしそうなら、なぜですか？基本クラスはメソッドを純粋な仮想として宣言しているため、派生クラスに存在する必要があるため、クラス定義の外部でメソッドを実装する前に、派生クラスでメソッドを再宣言する必要はありません。同意しませんか？

基本クラスに純粋な仮想代入演算子がある場合、その演算子を派生クラスに実装すると、基本クラスでリンカー エラーが発生するのはなぜですか?

現在、 http://support.microsoft.com/kb/130486に次の説明しかありません。通常の継承規則が適用されないため、動作は設計によるものであるとのことです。

私には明確ではありませんが、設計によりリンカーエラーが生成されるのはなぜですか? 誰かがこれについてもっと明確な説明をくれますか?

編集：エラーが発生した簡略化されたコードを追加しました：

コードは、基本クラスでの純粋な仮想 operator= 宣言の有無にかかわらず、エラーなし でコンパイルされます。__declspec(dllexport)

__declspec(dllexport)の割り当て後、d1:: memberB*bd1 = *bd2;は 1 ですが、__declspec(dllexport)d1::memberB がある場合は変更されません。

を使用し__declspec(dllexport)、pure virtual 宣言を使用しない場合、 の代入後*bd1 = *bd2;、d1::memberB は変更されません。

純粋仮想関数が DLL からエクスポートされないという奇妙な問題が発生しています。DLL がコンパイルされ、.dll ファイルとしてディレクトリに出力されます。ただし、.lib ファイルは生成されません。

私が定義を与え、それがもはや純粋な仮想として remian しなくなった場合、その後、喜んで .lib ファイルを作成します。

インターフェイスと実装を分離する必要があるファクトリ パターンを実装する必要があります。私のファクトリ実装と、必要な.dll（.libファイルが生成されていない）を使用する他のインターフェースは、そのエクスポートされた関数を使用する必要があり、それらの関数を使用するとリンクエラーが発生します...

「エラー LNK2011: 未解決の外部シンボル "public:......." など

純粋仮想関数をエクスポートして、他のexeおよびdllに実装できるようにする方法を考えてください

よろしくウスマン

Boost.Arrayのような単純なクラスがあります。テンプレートパラメータTとNは2つあります。Boost.Arrayの欠点の1つは、そのような配列を使用するすべてのメソッドが、パラメータN（TはOK）のテンプレートでなければならないことです。その結果、プログラム全体がテンプレートになる傾向があります。1つのアイデアは、T（ArrayInterfaceのようなもの）のみに依存するインターフェイス（純粋仮想関数のみを含む抽象クラス）を作成することです。これで、他のすべてのクラスはインターフェイスにのみアクセスするため、テンプレートパラメーターTのみが必要になります（Nとは対照的に、多かれ少なかれ常に知られています）。ここでの欠点は、インターフェイスが使用されている場合、仮想呼び出しのオーバーヘッド（インライン呼び出しの機会を逃す機会が増える）です。ここまでは事実だけです。

しかし、私の本当の問題はどこかにあります。Boost.Arrayをインターフェイスで拡張すると、Boost.Arrayの直接インスタンス化が遅くなります（重要な場合は、ファクター4）。インターフェイスを削除すると、Boost.Arrayは以前と同じように高速になります。ArrayInterfaceを介してメソッドが呼び出された場合、オーバーヘッドが発生することは理解しています。しかし、純粋仮想メソッドのみを含む追加のインターフェイスのみがあり、クラスが直接呼び出される場合、メソッドの呼び出しが遅くなる理由がわかりません。

GCC4.4.3とClang1.1は同じ動作を示します。