状況がはっきりしませんが、例えば異アーキテクチャのマシン間ではまずいですし、
おそらく 64bit Windows と 32bit Windows の間でもまずいでしょうし
同一アーキテクチャであっても異コンパイラで作ったソフト間ではまずいでしょう。

また stData の構造体の中にポインタメンバがあったり C++ でいうところの
virtual な機能が使われていたりしたら、同一コンパイラでもまずいです。

同一コンパイラで同一 alignment で同一 struct の sizeof が異なるというのは
限りなく考えられないので、どこかにミスがありそうです。
コンパイルオプションとか、ソースコードとか...

何も考えずに構造体を直接 Write/Read するってのは、
移植性(異マシン/コンパイラ)や拡張性(データフォーマット)とかを限りなく犠牲にして
ソースコードを簡単にする *手抜き* でしかないのでお勧めできません。

WriteとReadが同じにならなければなりません。
例えば「/Zp16」でファイルを作れば、「/Zp16」で読み込まなければならないです。

ALT + F7 --> C/C++ --> コード生成 --> 構造体メンバのアライメント

やっぱり、可変長のデータに変換して、
ファイル転送すべきでしょうか？
これが一番いい方法でしょうか？

>これが一番いい方法でしょうか？
「いい」という判断はねこサン自身で行ってください。何が「いい」かは案件次第なので。

開発期間短縮が最も求められるなら Read/Write するのがいいだろうし
遅い回線を通して遠隔地にデータを持っていくなら更に圧縮/伸張する必要があるだろうし
そのデータが人間に可読でなきゃならんならテキストにすべきだろうし
浮動小数点数をテキストにすると変換誤差も出るだろうし

転送ファイルのフォーマットを決めて
ファイルを作るようにしたほうがいいと思います。
サイズも、固定長でねこさんが数値で決めた方がいいです。
構造体のサイズで決めると仕様変更などが生じたときわからなく
なりやすいです。

ファイル形式は、tetrapodさんのご意見通りねこさんが決めてください。
途中でエクセルでチェックできるように「CSV形式」で保存する手もあります。
サイズが大きくなりますが..........

ＣのＡＰでファイル転送して、Ｃ＋＋のＡＰでファイルを受信しています。
ＡＰ間でアライメントが違っていますが、可変長の文字列を送信して、
これは解決しました。
が・・・、Ｃ＋＋のＡＰで受け取る時に使用する構造体が
Ｃで宣言している構造体の為アライメントが違い？、それをＣ＋＋で
宣言した構造体（同じ構造体）にいれると、値がこわれてしまいます。
どうすれば、いいのでしょう・・・

答えは既に述べられています。
構造体を丸ごとそのまま送るのでは問題があるのなら、
お互いが符号/復号できるフォーマットを定め、それに従います。

何で可変長なんですか。
文字列を固定長にすることは、出来ないのですか。
ファイルに保存する構造体に入るデータは固定長でないといけないと思います。

そして、ファイルのサイズは、その構造体より大きめのサイズの固定長に決めます。
余白の部分は、'00H'など分りやすい値で埋めます。

そうしないとうまくいかないと思いますが........

もしかして、
構造体にcharやunsigned char以外の変数
intやfloatなどを決めてませんか?
ファイルに書き込むときは、「charやunsigned char」
BYTE型にして書き込まないと値がこわれる可能性があります。

自分でフォーマットを決めてシリアライズ/デシリアライズしてるなら、
「その環境でそのフォーマットとして出力できる限り」、
int でも floatでも大丈夫だと思いますけど。

そうですBANさんの意見通り、
>「その環境でそのフォーマットとして出力できる限り」
　をしていれば可能です。

ただ、ねこさんの発言を見ると
　構造体に「intやfloat」が入っててもそのままファイルに書き込もうと
　しているふしがあったからです。

おかげさまで、ファイル転送する事ができました。
固定長でファイル転送する事にしました。
ちょっと、心配ですが。。。
可変長にしようとすると、かなりの改修要領になるので
やめました。
ファイル転送用のＴＢＬのヘッダーをインクルードする所によって、
アライメントが変わってくる事があるようで（よく分かりませんが）、
アライメントが変わらない所でインクルードを行う事で、解決？しました。