>時間がかかってもぜんぜん気にしないのであれば、
そりゃあ早いにこしたことはないですけどね・・・
実際、このアプリを使用する時は他のアプリケーションと同時に起動することはないで
しょう。
また、それを仕様とすることもできます。

＞512MBのログデータをRAMにずっと保持する
RAMに保持してある512mのログデータはASCII形式なのでBINARY形式に変換すると約半分
の256Mのデータ保持ですみます。
また、ログデータの保存領域を256Mにする(SRAMの領域全ては使わない)という話もあり
ます。この辺はまだ仕様が確定していません。

>時間かけていいならここでメモリーにコピーするのでなく、ハードディスクにコピーし
>たほうが楽
ハードディスクにコピー？プログラムでできるのですか？専用の構文などあるのです
か？

> RAMに保持してある512mのログデータはASCII形式なのでBINARY形式に変換すると
> 約半分の256Mのデータ保持ですみます。
それでもメモリー上に持つのはかなり難しいと思います。

＞ハードディスクにコピー？プログラムでできるのですか？専用の構文などあるのです
＞か？
そのまま、BINARY形式に変換して少しづつ保存していくようになると思います。
RAMのデータをどうやって取得するのか分らないのでこれ以上は説明のしようが
ないです。
専用の構文などはないと思いますが.......

> ハードディスクにコピー？プログラムでできるのですか？専用の構文などあるのですか？

？？？

# 活用できるかは設計次第だと思いますが、CreateFileMapping とか。

> 時間かけていいならここでメモリーにコピーするのでなく、ハードディスクにコピー
>したほうが楽ではないですか。
昨日はイメージわきませんでしたが、ハードディスクにコピーというのは、
変換したデータをファイルを新規作成して書き込み、保存しておくということですね？
それで検索する時は、このファイルをリードして行なう。
そうすればメモリを使わなくて済むと。

というか、通常は大きなデータならそうしますよ。
今でこそメモリが2GBなんてパソコンもありますけれど、
昔のPCなんて1MBも積んでませんでしたし。
大きなファイルは一度ハードディスク上に記録しておいて
検索上どうしても必要な情報のみインデックス化して
メモリ上に置くのが一般的な方法だと思います。

但し、ハードディスク上に置いても十分な検索スピードが出せるのであれば、
無理にメモリ上にインデックス等を置く必要はないです。
この辺は要求性能によるのでケースバイケースです。
メモリに置く物が少ないほど要求する動作環境は低くなるので
より使用環境を広げたいのであれば、考えるべきだと思います。

今さっき重大な問題が発覚しました。
勘違いしてました。。。
SRAMのサイズは512Mではなく、512Kでした・・・・・・・・・・

その中でログデータ領域に使用するサイズは、384Kか256Kになるようです。
なので、変換したデータは192Kか128Kになります。
それでも全変換データメモリ保持するのはよくないのでしょうか？

　う--む、たとえ512KBだとしても、時間が許せるならばデータメモリ保持と並列に
　ハードディスクに保存したほうがいいと思います。
　途中で停電などの事故がおきてSRAM上のデータが消えてもデータを保持できます。
　通常観測データ等、外部からの取得データは容量の大きい・小さいに関係なく、
　ハードディスク等に保存します。
　

私もITOさんに賛成ですね。
安全を見るなら不揮発な媒体にデータを保存しておいた方が安心です。
もっとも媒体が駄目になってしまうとそれまでですけれど。
それでもメモリ上に置いておいて停電等でデータが跳ぶ事に比べれば、
安全でしょうね。
特にトラブル時の対応に必要なデータなのであれば、
なおさら保存しておいた方が良さそうです。

>途中で停電などの事故がおきてSRAM上のデータが消えても
この装置は電源を切ることがないのです。
装置の寿命が10年ほどですが、その間フル稼働です。
もし停電が起きてもＵＰＳがついてるので少しの間なら平気です。
また、SRAMの情報は電源の供給が遮断されても5日ほどはもつそうです。
装置(SRAM)のある場所と僕のアプリを操作するＰＣはまったく別の場所にあります。
（100km以上離れている所もあります。）
僕のアプリを操作するＰＣ内のハードディスクにwebブラウザを用いてSRAMの情報をファ
イルに保存します。

僕のアプリはこのファイルを参照して検索、表示、保存などを行ないます。
この元となるファイルの仕様が変わりました。
年(2)、月(1)、日(1)、時(1)、分(1)、秒(1)、MS(2)、識別コード(1)、データ長(1)、デ
ータ(2^80)　　　＊()内はバイト数
と、STX,ETXのチェックをし、データを取り出し、バイナリーに変換されたデータををフ
ァイルに保存したものとなりました。

僕は、これを年～ms、識別コード、データと３つに分けファイルに保存することにしま
した。
んで、データ長とデータの先頭ポインタをメモリにもち、制御します。

検索した結果は、メモリ上で構造体に格納することにしました。

CArrayというのは、最初にSetSizeで配列の要素数を決めなければ、
Addで追加した分のメモリ領域しか確保されないのですか？

CArrayのソースを見てもらえばわかりますが、
なるべく new, delete をしないように
ある程度の領域をあらかじめ確保しておいて、それが足りなくなると
再確保するようなつくりになっています。
(CArrayのメンバのm_nMaxSizeがあらかじめ大きく取っておいたサイズ)

よって、
> Addで追加した分のメモリ領域しか確保されないのですか？
というわけではないです。

できるだけ、SetSizeであらかじめある程度の配列サイズを確保したほうがいいのでしょ
うか？
調べたところによると
Addでのみ追加すると、そのたびに拡張するので負荷が多くなる。
みたいですけど・・・
それよりも、毎回GetSizeを越えてないかチェックして
超えてないなら、SetAtで値を設定する。
超えてたらAddで追加する。
このようなやり方のほうが最適なのでしょうか？

＞それよりも、毎回GetSizeを越えてないかチェックして

意味不明でしたね。。
以下のように書き換えます。

最初にSetSizeである程度の配列要素数を設定し、
毎回GetSizeでm_nMaxSizeを超えてないかチェックする。

> そのたびに拡張するので負荷が多くなる
どこからその情報が？毎回拡張するわけではないですよ？

> 毎回GetSizeでm_nMaxSizeを超えてないかチェックする。
m_nMaxSizeはprotectedメンバなので参照できませんけど。
(CArrayを継承してそういうメソッドをつくるのでしょうか？)

というか、SetSizeで設定したサイズがGetSizeで取れるんじゃないでしょうか？

（１）とりあえず、格納されそうであるある程度のサイズをSetSizeで設定。
↓
（２）CArrayとは別に今まで格納した要素をカウントする変数を追加。
↓
（３）（２）で用意した変数を元に、Addで追加するか、SetAtで設定するかを切り分け
る。

適当な例)
CArray< int, int > arr;
int count = 0;

arr.SetSize( 10 );

for ( int i = 0; i < 20; i++ )
{
if ( count => arr.GetSize() )
{
arr.Add( i );
}
else
{
arr.SetAt( count, i );
}
count++;
}

# いつまで、このスレ続くのか。(レス数が40を超えるのもすごい)
# 質問がどんどん別のものになっているような。。。
# 結局CArrayつかうのかな？

> if ( count => arr.GetSize() )
GetSizeの値と比較するのは良くなさそう。
SetSize時の値と比較するように変更。
(しかも、比較演算子間違ってるし、、、)

CArray< int, int > arr;
int count = 0;
const int max = 10;

arr.SetSize( max );
for ( int i = 0; i < 20; i++ ){
if ( count >= max )
arr.Add( i );
else
arr.SetAt( count, i );
count++;
}