升級的記錄文件和向後兼容性

我有這樣的文件：升級的記錄文件和向後兼容性

file of record 
    Str: string[250]; 
    RecType: Cardinal; 
end;

但是使用這個文件我的客戶發現，該海峽永遠不會大於100個字符，也他需要更多的領域一段時間後。

在新版本中，我們有這樣的文件：

file of packed record 
    Str: string[200]; 
    Reserved: array[1..47] of Byte; 
    NewFiled: Cardinal; 
    RecType: Cardinal; 
end;

此記錄具有相同的大小，在海峽和RecType之間此前的紀錄是一個未使用的字節對齊時至8個字節。

問題：發生了什麼，當這個新文件將從舊代碼中獲得？他需要落後的兼容性。

舊代碼讀取樣本：

var 
    FS: TFileStream; 
    Rec: record 
     Str: string[250]; 
     RecType: Cardinal; 
     end; 
... 
// reading record by record from file: 
FS.Read(Rec, SizeOf(Rec));

來源

2013-02-15 Alex Egorov

您需要提供語言標籤和您的問題。對帕斯卡（或德爾福）不熟悉的人不知道你在這裏問了什麼，以及沒有標籤的人可能會錯過你的問題。 – 2013-02-15 00:22:56

你可以發佈一些讀取它的代碼嗎？ – placeybordeaux 2013-02-15 00:25:09

在我看來，編寫一個快速測試應用程序非常簡單，該應用程序以新格式寫入一些記錄，然後嘗試使用舊格式讀取它們;它會立即回答這個問題，並且會給你一個你可以用於未來變化的測試。 – 2013-02-15 00:37:45

老學校帕斯卡串使用字符串（索引0）的第一個字節來存儲該字符串的長度。

讓我們看看這個記錄的記憶：

byte 0 1 2 3 4 5 6 7 8 9 10 11 12 13 ........ 243..246 247..250 
value 10 65 66 67 68 69 70 71 72 73 74 0 200 130   NewField RecType

從11字節到242，內存可容納垃圾，它只是由程序（永遠不會顯示），因爲這需要在價值10忽略字節0作爲字符串的長度，因此字符串變成'ABCDEFGHIJ'

這保證了舊的程序讀取與最新版本創建將永遠不會看到垃圾在字符串末尾的文件，因爲視圖那條紋的 ngs將被限制爲字符串的實際大小，並且內存位置被忽略。

您必須仔細檢查舊程序是否更改存儲的值，以防將記錄寫回文件。我認爲這也是安全的，但我只是不確定，也沒有德爾福在手測試。

來源

2013-02-15 01:07:39 jachguate

我認爲字符串格式相同，並與舊程序客戶將查看數據沒有編輯 – 2013-02-15 01:16:39

很好地解釋，但問題是關於*舊代碼*閱讀*新記錄*。由於舊記錄將字符串定義爲50個字節，所以它確實可能包含一個字符串，它在某種程度上被錯過了，比新記錄中的200個字符更長（例如，如果存儲了實際的250字節字符串，或者一個由於某種原因填充了空格）。 – 2013-02-15 01:20:10

所有記錄不包含長度超過100個字符的字符串 – 2013-02-15 01:30:32

升級的記錄文件和向後兼容性

回答

相關問題