我正在研究 GLSL 著色器程式加載器。著色器程式只是帶有源代碼的純文本。我可以通過以二進制模式呼叫來打開它們fopen()，這很容易。但是由于我的源檔案是文本，我是否應該正確使用fopen()不帶二進制標志的文本檔案并逐行讀取它們？逐行連接整個文本更乏味，并且行緩沖區長度被fgets(). 因此，如果有任何行長于緩沖區，則讀取將失敗。但是程式……順便說一句，它們是文本檔案……以二進制模式讀取文本檔案有什么缺點？可能會出現編碼或行尾問題？我該怎么辦？我應該以二進制模式還是文本模式閱讀它們？
uj5u.com熱心網友回復：
/標志只是關于換行符轉換binary。只是按原樣通過換行符，會將運行程式的作業系統通用的換行符序列轉換為簡單的單位元組換行符。GLSL 編譯器根本不關心它看到什么樣的換行符（Unix 風格、Windows/DOS 風格、RISC OS 風格），無論如何，它都是空白。textfopenbinarytext\n\n\r\n\n\r
也沒有必要用分割線來呈現 OpenGL。這glShaderSource需要一個字串陣列是為了方便，這樣您就可以擁有一些常見的著色器字串，您可以將它們作為標題或類似內容放入源字串向量中。但是只提供一個長字串就很好了。
uj5u.com熱心網友回復：
如果要將檔案作為行處理，則應以文本模式打開檔案。文本模式自動將作業系統的換行符轉換為\n. 所以在 Windows 上，\r\n序列將被轉換為\n，并將fgets()用作\r\n行分隔符；在 Unix 上，換行符已經是\n，所以不需要翻譯，二進制和文本模式之間沒有區別。
uj5u.com熱心網友回復：
在文本模式下讀取文本檔案的一個缺點。
- 跨平臺使用。
在其本機平臺上的文本檔案可以在文本模式下打開。"\n"然而，如果檔案在系統中被讀取，跨平臺作業很容易破壞檔案處理"\r\n"- 反之亦然。
為了很好地處理這個文本檔案的變化，我們至少需要測驗4 個條件：
"\n"檔案在"\n"系統中被讀取。"\n"檔案在"\r\n"系統中被讀取。"\r\n"檔案在"\n"系統中被讀取。"\r\n"檔案在"\r\n"系統中被讀取。
如果檔案被讀取為二進制檔案，我們擔心一半的情況，2，因此具有測驗優勢。
"\n"檔案。"\r\n"檔案。
我們可以在上述兩種情況下讀取一行fgets()，然后使用通用代碼洗掉潛在的行尾：
buf[strcspn(buf, "\n\r")] = '\0';
然而這就夠了嗎？
這并不是真正的，因為一些較舊的系統已經知道'\r'用作終端。在這種情況下，上面的代碼是不夠的，因為fgets()找不到'\n'.
上面的代碼還假設'\r'除了行尾不出現。
其他注意事項
引導位元組可以是byte-order-mark。
最后一個位元組可能是 aCtrlZ并且不是真正的文本的一部分。
由于假設某個結尾的混合歷史編輯器，行尾可能是
"\n"、"\r\n"、或其他的混合。"\r"最后一行可能/可能不會以適當的行尾字符結束。
窄字符與寬字符。
未來：通過以文本模式打開，我們依靠當前系統來處理當前的文本檔案格式，而不僅僅是我們在撰寫代碼時所知道的那些。
底線
除非可以跨平臺使用，否則請使用文本模式。
否則對文本檔案使用二進制模式并準備處理許多文本檔案標準。（IMO：這意味著將檔案的至少一部分作為二進制檔案讀取，分析它是什么型別的文本檔案，然后繼續進行精心制作的文本處理或以文本模式重新打開作為后備案例。）
uj5u.com熱心網友回復：
我看到“適合專家的東西不適合新手”。如果你想繼續，這里是你的路徑：
- 被告知不
- 試著去做
- 了解為什么不
- 適應
- 學習
- 開發作為輸入庫鏡像的庫
- 發現“否”已成為“是”。
還是只是復制檔案？如果是這樣，沒問題。打開并復制。
在過去，我們有關于文本檔案的事情；您在打開它們時獲得了平臺的行為，并且在系統之間復制檔案時，您必須轉換行尾。
那些日子正在過去；每個人都放棄fopen了文本模式，只使用簡單的狀態機接受任何行尾。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/455479.html