> ちなみにですが、CArrayの各要素のポインタって取れましたっけ？
> CArrayのソースを見ればわかるかもしれませんけれど。

CArray::GetDataで、先頭が取れますが、
これを積極的に使うならばCArrayを使う意味がないですね。

なるほど、そういう方法もありますね。
CArray<KATA*>のほうが楽かもしれませんね？
でも2バイトずつ増えますね。

>ちなみにですが、CArrayの各要素のポインタって取れましたっけ？
各要素のポインタとは？どういう意味？

CArray内の要素の管理はCArrayがやっていますから
内部にあるデータにいつも直接アクセスしているとは限らないと言う意味です。
例えば、GetAtした場合、返却される参照先のインスタンスは一時オブジェクトで
ある可能性があるということです。基本的にクラスが内部に持っているデータを
直接扱うことを避ける設計をします。この方がデータの安全性が高いからです。
CArray::GetDataで先頭ポインタが取れますが、CArrayにAddしたタイミングで
内部的なメモリの再確保が発生して先頭のポインタが変わる事だって考えられます。
クラスを使う場合、その辺の事まで考えておかないといけません。

CArrayを使う設計で動的にメモリを確保して使うのであれば、
インデックスを保持する方法の方が自然な実装だと思います。
CArrayそのものもインデックスでアクセスする事を基本にしたクラスですから。
ポインタの配列でデータを扱うのであれば、m_defはKATAのポインタで宣言して
newで配列確保した方が自然でしょう。
後考えられるとしたら、ポインタの配列でm_defを作成しておいて
m_1・・・側もポインタの配列にするとかかな。
この場合は、m_def要素を追加するたびにnew KATAが必要になりますけどね。
やり方は色々あるので試行錯誤してベストを探るのもまた勉強ですね。

失礼、脱字。

誤）
> この場合は、m_def要素を追加するたびにnew KATAが必要になりますけどね。

正）
この場合は、m_defに要素を追加するたびにnew KATAが必要になりますけどね。

>これは必要ないと思います。
>というか、これを何に使うのでしょう？
>ねこたまさんの書き方が出来る時点で必要ないと思いますけれど。
>なぜ、必要なのかが理解できないです。
これに関してそもそもの質問の根源なのですが、
検索条件を判定し、m_1～m_5にセットするのですが、
判定する元のデータがm_defを直接見るか、
m_1～m_4でインデックスを取得するかで処理が変わります。
それをうまく統一できないかな～と思いまして。。

m_KenskuNumの値により検索元のデータを決めます。
一度も検索してない時は0（m_defを参照し、m_1にセット）。
0のときと、1～4のときでif文で分ける必要があります。

>CArrayを使う設計で動的にメモリを確保して使うのであれば、
>インデックスを保持する方法の方が自然な実装だと思います。
僕もそう思います。

この方法で設計してみます。
この方法がやはりベストだと思うので！

m_0はいいアイデアだと思いますよ

さらにm_0～m_5を纏めて
CArray<WORD,WORD> m[6]; というのもありかも・・

>m_0はいいアイデアだと思いますよ
そう思いますか？よかった。
>CArray<WORD,WORD> m[6]; というのもありかも・・
これが一番シンプルですねぇ(^o^)

> これに関してそもそもの質問の根源なのですが、
> 検索条件を判定し、m_1～m_5にセットするのですが、
> 判定する元のデータがm_defを直接見るか、
> m_1～m_4でインデックスを取得するかで処理が変わります。
> それをうまく統一できないかな～と思いまして。。

この部分を無理に一つの処理で行おうとするからかえって面倒になるのでは？
検索を行った場合と行わない場合でばっさり処理を分けてしまうのも手でしょうし、
例えば、こんな方法もありだと思います。
（コンパイルは通していないので参考程度に）

メンバー変数に
CArray<WORD,WORD> m_index[5];
としておいて

int countMax;
if(m_KenskuNum == 0)
{
countMax = m_def.GetSize();
}
else
{
countMax = m_index[m_KenskuNum - 1].GetSize();
}

int iIndex;
for(int i = 0; i < countMax; i++)
{
if(m_KenskuNum == 0)
{
iIndex = i;
}
else
{
iIndex = (m_index[m_KenskuNum - 1])[i];
}

// この辺で参照する。
m_def[iIndex]とすれば、参照可能。
}

この辺は設計と言うよりもコーディングのレベルの話ですね。

確かにm_0に相当する物があれば、if文はいらなくなりますね。
ただ、この場合は逆にm_KenskuNum==0の場合だけが違う処理なんだということが
わかった方が後から見たと気に直感的にわかっていいような気もします。

>例えば、こんな方法もありだと思います。
その方法はまずまっさきに思いつきました。
しかし、for文の中でif文で毎回判定するのはよくないかな！？と、思いました。
最大で16000回も判定するもんで・・・

そして、
＞int iIndex;
のあとにまずif文で分けてしまい、
それ以下の処理を両方に記述する方法にしようとしました。
しかし、違うのは、iIndexに代入するまでの2行ほどで
以下は同様です。
なので同じ処理を何行も記述するので
無駄かな？美しくないな？と思いまして、
なんかいい方法はないかと質問させていただきました。

その中でm_0の方法を思いつきました。
それならif文が必要なくなります。
メモリは2*16000無駄になりますが・・・

>確かにm_0に相当する物があれば、if文はいらなくなりますね。
>ただ、この場合は逆にm_KenskuNum==0の場合だけが違う処理なんだということが
>わかった方が後から見たと気に直感的にわかっていいような気もします。
う～ん、それは人によりますね。
判定がいっぱいあったほうが追いづらい人もいるし、
俺は・・・どっちだろう？
まぁ、この場合この０だけ違うというのを忘れることはないと思いますけど。
そう思うならm_0の方法がよいのかな？

あうあう。また誤字が。

誤）
わかった方が後から見たと気に直感的にわかっていいような気もします。

正）
わかった方が後から見た時に直感的にわかっていいような気もします。

まあ、この辺は個人の好みの範疇でよいのではと思います。
今時のPCであれば、この程度のif文なら足を引っ張るほどにはなら無そうですし。