1

基本的に、c_stringから継承するカスタム ユーティリティ クラスを使用する大規模なプロジェクトがありますstd::basic_string<char>。さまざまな理由から、このクラスを編集して、

  1. から派生したものではありませんstd::basic_string<char>
  2. すべての機能を再実装する必要はありません
  3. を使用するすべてのファイルに触れる必要はありませんc_string

だから私はから変更したい：

class c_string : public std::basic_string<char>
{
public:
    typedef std::basic_string<char> Base;

    c_string() : Base() {}
}

に：

class c_string
{

...

public:

    ...

    c_string() {...}
}

ですから、影響を最小限に抑えてこの変更を行うための優れた戦略を誰かが持っているかどうか疑問に思っています.

4

4 に答える 4

2

クラスが（プロジェクトに必要な）カスタム機能を追加する場合std::stringは、運が悪いです。カプセル化するstd::string（そして実装に転送するすべてのメソッドをstd::string実装する）か、継承するstd::string（から継承するstd::stringのは良い考えではありません）必要があります。全般的）。

クラスがに機能を追加しない場合はstd::string、に置き換えclass c_string { ... }ますtypedef std::string c_string;。

于 2013-01-31T16:13:26.990 に答える
1

できることはもう 1 つあります。それは、公開継承を非公開継承に変更することです。これを行うと、文字列のすべてのメンバー関数がクラスのクライアントに対してプライベートになるため、一連のコンパイル エラーが発生します。次に、これらを選択的に公開できます。

class my_string: std::string {
public:
    typedef std::string base; // convenience
    using base::const_iterator;
    using base::begin;
    using base::end;
};

「my_string は std::string です」ではなく、「my_string は std::string の観点から実装されている」というプライベート派生を理解する必要があります。この手法は、std::string のように、基本クラスになることを意図していない型から派生することのいくつかの欠点 (暗黙の変換、スライスなど) を回避します。この変換を行うのは簡単です。何かを壊すリスクはほとんどありません。ただし、その後は、転送されたインターフェースを制御できるため、変換とリファクタリングがはるかに簡単になります。

于 2013-01-31T20:01:20.197 に答える
0

少なくともすべての関数をラップすることを回避できる方法はわかりません。最も簡単な方法は、プライベートのbasic_stringメンバーを作成し、そのメンバーで同じ関数を呼び出すラッパーを作成することです。

于 2013-01-31T16:13:32.217 に答える