boost.png (6897 bytes) Filesystem 庫
Boost Home    Library Home    Tutorial    Reference   FAQ

常見問題

為什麼基於 POSIX 的通用路徑字符串格式?

[POSIX-01] 是一個ISO標準。它是大多數常見的路徑字符串格式的基礎,它不僅僅是 POSIX 系統的,而且還是原生的 Windows 格式和 URI 的 URL 部分的格式。它到處存在,十分常見。在許多系統上,它非常易於實現,因為它既是原生操作系統的格式(Unix 和 Windows),也適用於提供了 POSIX 庫的操作系統(z/OS, OS/390, and many more)。

為什麼不使用完整的基於 URI (通用資源標識符)的路徑?

URI 承諾的比 Filesystem 庫實際可提供的要多得多,因為 URI 比多數操作系統所考慮的文件或目錄要延伸得更多。因此,出於 Filesystem 庫的主要需求 "可移植的腳本式文件系統操作",完整的 URI 顯得過於規範了。

為什麼 path 不是 directory_pathfile_path 的基類?

為什麼要擔心?  這三個類的行為本質上是一樣的。有幾個早期版本曾經要求用戶標識出每個路徑是文件還是目錄,這似乎增加了錯誤並降低了代碼的可讀性。這樣做並沒有明顯的好處。

為什麼完整的路徑被稱為 complete 而不是 absolute?

為了避免那些使用單根文件系統的程序員的假設(你是否知道,在有些系統上,"/foo" 不是絕對的?)。使用一個不常見的名字來表示這一概念和相關函數,可以讓程序員去閱讀規格說明而不僅是假設已經知道這些概念的意義。

為什麼不支持特定類型的文件系統概念,如 posix_file_system 或 windows_file_system.

可移植性是本庫的一個最重要的需求。而通過使用特定操作系統的特定特性以獲得好處並不是一個需求。當運行在一個 OpenVMS 機器上時,似乎不太可能需要操作一個 Mac OS路徑的能力。

此外,"文件系統"這樣的概念是很含糊的。例如,當一個 NTFS 或 FAT 文件掛載在一個運行類 POSIX 操作系統的機器上的某個目錄時,會發生什麼?有些 POSIX API 可能會返回非常不像 POSIX 的結果。

為什麼不提供一個 '句柄' 類型,並以之進行文件和目錄操作?

在這樣的系統上是否有可行的方式滿足"可移植腳本式文件系統操作"的需求,並不清楚。文件系統中有一些操作常常以非字符串的句柄類型來執行。但 Mac OS 已經明確提到一種情形,這樣來處理路徑並不自然。

"句柄"風格(用不透明的數據類型來標識一個文件)可能是最強大的目錄迭代器值類型。(請見 Jesse Jones' Jan 28, 2002, Boost postings)。但是,由於類 path 的發展,看起來它已經可以作為目錄迭代器值類型了。

為什麼 operations.hpp 的非成員函數如些低層?

為了提供一組可以由此創建高級功能的工具集。

在底層功能之上增加其它便利函數,或替換它們的嘗試都失敗了,因為對於最多考慮的便利函數,沒有一套得到廣泛接受的簡單語義。試圖通過運行期選項或 編譯期策略提供不同的語義,涉及到值的交付,過於複雜或是有異議。OTOH, 對於幾個應用程序所需要的特殊功能,用戶可以很容易地從底層工具函數構造得到。請見 失敗的嘗試

Isn't it inconsistent then to provide a few convenience functions?

是的,但是本庫,POSIX, 以及 Windows 的經驗都表明,某些便利函數的用處,而且有可能提供簡單的、被廣泛接受的語義。例如,remove_all.

為什麼 operations.hpp 的謂詞函數有 basic_directory_iterator<> 重載? 難道用兩種方法來做同一件事不是壞的設計嗎?

是的,用兩種方法來做同一件事通常都是壞的設計。但是函數的迭代器版本通常更為高效。在一個有15,000個文件的目錄中進行遍歷並調用 status(),使用 path 的重載版本需要6秒鐘,而使用迭代器的重載版本則只要1秒鐘,這是在剛剛啟動的機器上測試的結果。如果在已訪問過的目錄上測試,則時間分別為.90秒和. 30秒。這些性能上的提高足以讓我們背離完美的設計。沒有一個重載可以滿足所有需要。

為什麼庫函數對於錯誤如此挑剔?

安全性。缺省情況下安全總比抱歉好。尤其重要的是,在許多計算機系統中,文件和目錄是 全局共享的 資源,因此可能會遇到不期望的錯誤。

為什麼以異常而不是返回碼或錯誤通知變量來報告錯誤?

安全性。返回碼或錯誤通知變量經常會被程序員所忽略。異常很難被忽略,提供了想要的缺省行為(如果不捕獲則退出程序),如果想要的話,也允許錯誤恢復。在經驗表明需要的地方,也提供了無拋出的函數版本。

為什麼通過命名函數而不是屬性映射來訪問屬性?

對於常用的屬性(存在性,目錄或文件,是否為空),這樣比其它方式具有簡單的語法且保證存在。因為訪問更多其它屬性是與系統相關的,屬性映射看起來 最適用於訪問和修改,但是更好的設計是在一個單獨的庫中提供這些功能。(歷史說明: 即使象"只讀"這樣簡單的屬性也是與系統相關的,都不能被作為一個"保證存在"的操作。)

為什麼不支持寬字符名字? 為什麼沒有 std::wstring 或某個模板類型?

它們是被支持的,從版本1.33開始。請見 國際化

為什麼不提供自動的名字可移植性錯誤檢查?

曾經評估過多個(至少六個)名字有效性錯誤檢查的設計,其中至少有四個已完全實現。它們被拒絕的細節原因各有不同,所有較強大的名字有效性檢查的設 計都影響了本庫其它方面的簡單性。即使是本庫原先版本所提供的簡單的名字檢查,也成為了用戶投訴的固定來源。雖然名字檢查有所幫助,但是它的重要性還不足 以成為增加如此多複雜性的理由。

為什麼有時用成員函數來操作路徑,有時又用非成員函數?

設計原則是,純字面的操作以 class basic_path 的成員函數方式提供,而由操作系統執行的操作則以普通函數的方式提供。


Revised 18 March, 2008

c Copyright Beman Dawes, 2002

Use, modification, and distribution are subject to the Boost Software License, Version 1.0. See www.boost.org/LICENSE_1_0.txt