>いちおGoogleで検索はして色々見てみたのですが・・・
　私も最近、STLのvectorを利用しましたがすぐに見つかりましたが・・・

サンプルソース
http://www.geocities.jp/ky_webid/cpp/library/002.html

vectorの詳細
http://www.wakhok.ac.jp/~sumi/stl/header/vector.html

　前のすれの続きとしたら　MFCを利用されているんですよね？？それなら　CArrayとか
使えばいいと思います。私は　よくCPtrArrayクラスをよく利用します。
http://www.alpha-net.ne.jp/users2/uk413/vc/VCT_COb.html

最後に
>二つの使い方がわかりません
とありますが、どういったことがわからないのですか？？配列に格納する方法？？配列
に入ってるもの？？それともCArrayクラスそのもの？？　何がわからないかを言って頂
かないとなんとも返答しにくいです。
　

> どういったことがわからないのですか？？配列に格納する方法？？配列
> に入ってるもの？？それともCArrayクラスそのもの？？　
> 何がわからないかを言って頂かないとなんとも返答しにくいです。
どうやら、「動的配列を扱ったことがないので普通の配列の使い方で
いいか分らない。」と言いたいのかなと思います。

意見としても書いたのですが、何でリングバッファしたいのか分らないです.
リングバッファしたいのなら「CList」を使う方法もあると思います。

色々なご意見ありがとうございます。
別件で忙しかったものでまだ全然調べていないのですが。

>1.　512MBのSRAMは何ですか。
>2.　リングバッファにする必要性は何ですか。

あるソフトがSRAMにデータをロギングします。
このソフトはSRAMをリングバッファとしてロギングします。
先頭4バイトにライトポインタを保存しておきます。
最大ロギングデータ数はディファイン定義どおり、27593バイトです。
リングバッファなので古いデータは上書きされます。

別のアプリでSRAMの情報を全てファイルにロギングします。

僕の作るアプリでは、ファイルをリードしロギングデータを取り出します。
ロギングデータはASCII形式なので、BINARYまたは文字情報に変換して
ダイアログ上のリストビューに表示します。
（表示数に関しては仕様は決まっていませんが・・・
制限が必要かもしれません。）

さらに、この中で色々な検索方法（何月～何月、何時～何時など・・）に該当するデー
タを表示し直します。
最後に現在表示されているデータをファイルにロギングする機能をつけます。

＞#余計なお世話かもしれなませんが、スレ主さんは、頂いたレスをちゃんと見ているの
＞だろうか。。。

見てます。見てもわからなかったもので

＞使い方にしてもMSDNを調べるとかすれば、簡単な使用例は出ています。
みました。さっぱりわかりません。
今までメモリの動的確保をしたことがありませんでした。というか、使用方法など調べ
たこともありませんでした。
Ｃ＋＋自体２年ぶりぐらいで、ここ最近は純粋なCばっかりでしたので・・・

>> 使い方にしてもMSDNを調べるとかすれば、簡単な使用例は出ています。
> みました。さっぱりわかりません。
> 今までメモリの動的確保をしたことがありませんでした。というか、使用方法など調べ
> たこともありませんでした。
> Ｃ＋＋自体２年ぶりぐらいで、ここ最近は純粋なCばっかりでしたので・・・

さっぱりわからないのでしたら勉強しなおすしかないと思います。
2年ぶりとは言っても2年前にテンプレートライブラリが無かったのかというと
そんな事は無かったと思いますし。
少なくとも理解しないで使うのは非常に危ない状況だと思います。

他の方も何回か書いていいたと思いますが、
汎用性の高いアプリなのか専用のアプリで動作環境を選んでも良いのかによって
話は180度変わります。ですから、特定の用途向けの専用アプリであり、
使用環境を制限する（最低スペックを明示してそれ以下は動作保障なしとか
他のアプリケーションとの同時起動は不可と言うような話）であれば、
それを基準に考えれば済むはずなのでオンメモリに取ろうが、他に上がっている
アプリケーションがほとんど動かないような状況になろうが仕様ですという
話なのでそれはそれだと思うのですけれど、その辺がどうもハッキリしてない
と思います。

> あるソフトがSRAMにデータをロギングします。
> このソフトはSRAMをリングバッファとしてロギングします。
> 先頭4バイトにライトポインタを保存しておきます。
> 最大ロギングデータ数はディファイン定義どおり、27593バイトです。
> リングバッファなので古いデータは上書きされます。

メモリ上にロギングするのが仕様の必須条件なのであれば、
逆に動作環境はこのメモリが確保できるハードが必須となると思います。
但し、この仕様だと汎用性に関しては低くなると思います。
汎用性が低くてよいのであれば、そう明言してしまった方が話が早くなります。

>あるソフトがSRAMにデータをロギングします。
あるソフトとは何ですか。
差し支えなければ........
>Ｃ＋＋自体２年ぶりぐらいで、ここ最近は純粋なCばっかりでしたので・・・
だとすると、「Vector」を使用するならもう一度「C++」を（特にテンプレート）
を本で勉強しなおしたほうがいいです。

>テンプレートライブラリ
今回で初めて存在を知りました。勉強します。

＞汎用性の高いアプリなのか専用のアプリで動作環境を選んでも良いのか
汎用性は高くないです。基本的にシステムに問題があった時にログを吸い上げて、
どの箇所で問題が発生したか切り分けるために用います。

＞あるソフトとは何ですか。
CLINUX上で動くソフトです。ＣＰＵはＳＨ４です。
ソフトは受信した制御指令通りに接続された装置の設定を変更します。
また、現在の装置の状態を監視し、送信します。

例えばの話ですが、
メモリを山ほど積んでいて512MBのメモリを確保できない場合はエラー終了しても
良い様なソフトならnewで一気に確保もありでしょう。
メモリ不足でエラーメッセージを表示して終了するのも仕様という事になります。
但し、それはあくまでもそれが仕様として許されるのであればという話です。
それは駄目だ、最低限このくらいのメモリのPCでも動作しないと使い物にならないと
いう話なのであれば、そもそも512MBものメモリが確保できないと動かないような設計が
間違っているという事になります。仮にスワップを許してまで確保したとしても
それではパフォーマンスが大幅に落ちると思います。
そういう意味ではどの程度のハードまでを動作対象にするのかがきちんと設定されて
いないとパフォーマンスと要求動作環境のバランスをとる事が出来ないはずです。
例えば、画面に100レコード一ページとして表示するような仕様にするのであれば、
100レコード分だけメモリ上に確保するようにすれば、表示はできるはずです。
検索を行う場合は、ログファイルに対してファイル上で行う事も可能でしょうし、
検索のために起動時にインデックス化した内容をメモリに保持するという方法も
あるでしょう。
要は必要なパフォーマンスを出しつつ、何処まで動作環境を緩和できるかという話ですよね。
メモリに置いておけば速いのはわかりきっていますし、アクセスも楽ですが、
それだけなら技術的な工夫はほとんどないのと同じだと思います。
省メモリでパフォーマンスをどれだけ出せるかが技術者の腕の見せ所でしょう。
（この辺はアプリに対する要求仕様による話ですから一概には言えないとは思いますけれど）

>CLINUX上で動くソフトです。ＣＰＵはＳＨ４です。
>ソフトは受信した制御指令通りに接続された装置の設定を変更します。
>また、現在の装置の状態を監視し、送信します。
了解しました。
僕が「あるソフトとは何ですか。」と聞いたのは、512MBものSRAMを使用するには、
それなりの手段、PCIボードにSRAMが搭載していてドライバーを介してデータを取得
するとか、単にUSBメモリーで1ドライブとなる等あると思ったので
聞いたのですが..............

っていうかそもそも最初の前提から間違っている気がする

俺なら512MBのログデータをRAMにずっと保持する設計など絶対しない。意味ないもの。
それに512MBのログを全てダウンロードするためにはそれなりの時間がかかりそう。
データをダウンロードし終わるまで何も出来ないくらいなら
今必要な少量のデータだけダウンロード＋保持するほうがマシ

ターンアラウンドタイムとレスポンスタイムの違いってわかってるのだろうか？

>メモリを山ほど積んでいて512MBのメモリを確保できない場合はエラー終了しても
>良い
それはないです。少なくてもなにかしら表示はしないとまずいですね。

>そういう意味ではどの程度のハードまでを動作対象にするのかがきちんと設定されて
>いないとパフォーマンスと要求動作環境のバランスをとる事が出来ないはずです。
このアプリを使用するPCのスペックはある程度決めることはできますが、
既設のPCを使用する場合もあると思うのでなんともいえないです。

＞要は必要なパフォーマンスを出しつつ、何処まで動作環境を緩和できるかという話で
＞すよね。
その通りです。

>それに512MBのログを全てダウンロードするためにはそれなりの時間がかかりそう。
時間はかかると思いますが、そこは特に問題ないです。
メモリ容量が平気なのであれば、512Mのファイルを一時バッファにコピーし、構造体配
列のデータに変換して、全データ保持しておきたいです。
変換したデータでないと、検索するのがかなり面倒になるので・・・

時間がかかってもぜんぜん気にしないのであれば、
一件一件変換しながら検索しても別に問題ないような気もします。
気になるなら、バックグラウンドのスレッドで処理するとか。

リングバッファでログ…これだけみると、
std::vector で中身を自前管理するほかにも、std::deque あたりも選択肢にあがるかな。
# とか書くと更に混乱させそうな気もしますが、終端への追加と削除に向いたコンテナです＞deque

いっそ、DBにでも入れちゃった方がメモリ管理や検索含めで楽なのでは？

>時間はかかると思いますが、そこは特に問題ないです。
>メモリ容量が平気なのであれば、512Mのファイルを一時バッファにコピーし、構造体配
>列のデータに変換して、全データ保持しておきたいです。
時間かけていいならここでメモリーにコピーするのでなく、ハードディスクにコピーし
たほうが楽ではないですか。
Banさんの意見にもある通り、DBに保存するのもいいと思います。

> 時間かけていいならここでメモリーにコピーするのでなく、ハードディスクにコピーし
> たほうが楽ではないですか。

私もこの意見に賛成です。
今時のハードディスクはかなり早いですからね。
検索に使うキーが限られるのであれば、データは一旦ハードディスクに書き出して
検索用のインデックスのみをメモリ上に持つという方法もあるのではないですか？
動作環境を選ぶようなソフトにしたくないのであれば、
全てをメモリ上に持つという発想自体に無理があると思いますよ。