2

boost::multi_index_containerランダムアクセスとorderd_uniqueを同時に使用する際に問題が発生します。（長い質問で申し訳ありませんが、例を使用する必要があると思います。）

次に例を示します。ファクトリでN個のオブジェクトを作成し、オブジェクトごとに満たす必要があるとします（この要求は、マルチインデックスの作成時にわかります）。さて、私のアルゴリズム内で、次のクラスに保存する中間結果を取得します。

class intermediate_result
{
private:
    std::vector<int>   parts;     // which parts are produced
    int                used_time; // how long did it take to produce

    ValueType          max_value; // how much is it worth
};

オブジェクトが生成されるベクトルpartsdescibes（その長さはNであり、辞書式順序で私のcorespデマンドベクトルよりも小さいです！）-そのようなベクトルごとに、used_timeも知っています。さらに、生成されたオブジェクトのこのベクトルの値を取得します。

すべてのオブジェクトを生成できないように、別の制約があります。アルゴリズムintermediate_resultでは、データ構造に複数のオブジェクトを格納する必要があります。そして、ここboost::multi_index_containerで使用されます。これは、とのペアが一意partsをused_time記述しているためですintermediate_result（そして、データ構造内で一意である必要があります）がmax_value、アルゴリズムは常にintermediate_result最高のを必要とするため、これは考慮しなければならない別のインデックスmax_valueです。

そこで、「parts＆used_time-pair」と（異なるオブジェクトが同じ値を持つ可能性があります）にを使用してみましたboost::multi_index_container。ordered_unique<>ordered_non_unique<>max_valueintermediate_result

問題は次のとおりです。どの「parts＆used_time-pair」が小さいかを判断するために必要な述語は、std::lexicographical_compare私のparts-vectorで使用するため、多くのオブジェクトで非常に低速ですintermediate_result。しかし、解決策があります。各オブジェクトに対する私の需要はそれほど高くないので、可能な各部分に格納できます。中間結果をそのによって一意にベクトル化しますused_time。

たとえば、デマンドベクトルがある場合は、可能なパーツベクトル( 2 , 3 , 1)を格納するデータ構造が必要です。(2+1)*(3+1)*(1+1)=24そのようなエントリごとに、一意である必要がある異なるused_timesが必要です。（最小の時間を保存するだけでは不十分です。たとえば、追加の制約が次の場合：本番環境で特定の時間を正確に満たすため）

random_access<>しかし、 -indexと-indexを組み合わせるにはどうすればよいordered_unique<>ですか？
（Example11はこれについては役に立ちませんでした。）

4

2 に答える 2

2

2 つのインデックスを使用するには、次のように記述できます。

indexed_by<
  random_access< >,      
  ordered_unique< 
    composite_key< 
      intermediate_result,
      member<intermediate_result, int, &intermediate_result::used_time>,
      member<intermediate_result, std::vector<int>, &intermediate_result::parts>
    >
  >
>

必要な場合にのみ、最初composite_keyの比較に使用できます。それに加えて、メンバー関数をインデックスとして使用できることに注意してください。used_timevector

于 2009-11-09T11:26:48.010 に答える
0

（コードブロックを書くために独自の答えを使わなければなりませんでした - ごめんなさい！）

composite_keywith used_timeand (Kirill V. Lyadvinsky が提案したpartsように) は、基本的に私が既に実装したものです。parts-vectorの辞書式比較を取り除きたいです。

何らかの形でneeded_demandを保存したと仮定すると、次のようなランダムアクセスデータ構造内で正しいインデックスを返す単純な関数を書くことができます: 

int get_index(intermediate_result &input_result) const
{
    int ret_value  = 0;
    int index_part = 1;
    for(int i=0;i<needed_demand.size();++i)
    {
        ret_value  += input_result.get_part(i) * index_part;
        index_part *= (needed_demand.get_part(i) + 1);
    }
}

明らかに、これはより効率的に実装でき、必要な需要に対して可能な唯一のインデックス順序付けではありません。intermediate_resultしかし、この関数が!のメンバー関数として存在するとしましょう。防止するためにこのようなものを書くことは可能lexicographical_compareですか？

indexed_by<
  random_access< >,      
  ordered_unique< 
    composite_key< 
      intermediate_result,
      member<intermediate_result, int, &intermediate_result::used_time>,
      const_mem_fun<intermediate_result,int,&intermediate_result::get_index>
    >
  >
>

これが可能であり、可能なすべてのベクトルでマルチインデックスを初期化した場合parts(つまり、上記のコメントでは、データ構造に 24 個の空のマップをプッシュしたことになります)、これintermediate_resultは一定時間内に指定された正しいエントリを見つけますか ( )で正しいインデックスを計算した後get_index? インデックスがインデックスとどのようにリンクされているの
かよくわからないので、これを尋ねなければなりません..random_access<>ordered_unique<>

でも、今まで答えてくれてありがとう！！

于 2009-11-09T13:10:31.733 に答える