状態のドキュメントboost::filesystem::canonical(const path& p):
概要: 存在しなければならない p を、シンボリック リンク、ドット、またはドット ドット要素を含まない絶対パスに変換します。
...
備考: !exists(p) はエラーです。
この結果、p がターゲットが存在しないシンボリック リンクを識別した場合、関数は失敗しfile not found、パスを返しません。
リンクのターゲットが存在しないという理由だけで、関数がその存在しないターゲットのパスを解決できない理由がわかりません。（これに比べて、absolute()はそのような制限を課していません。）
(明らかに、パス内のシンボリック リンクが壊れている場合、ターゲット パスは解決できません。)
では、この制限には正当な理由がありますか?
また、あるとしても、この制限を持たない関数のバリアントを作成することも正当化されませんか? (このようなバリアントがなければ、パスを取得するには、canonical()既に行っていることの 99% を手動で複製する必要があり、エラーが発生しやすくなります。)
stat()このケースの間に存在するセマンティックな機微が、lstat()このケースにも等しく適用されることを理解しています。これがまさに、関数のバリアントが等しく正当化されると考える理由です。
注意: この質問は、に基づいているstd::experimental::filesystemライブラリ ( n4100boost::filesystem ) にも同様に当てはまります。
編集：
以下の@Jonathan Wakeleyの非常に知識豊富な回答の後、元の質問の本質が残っています。これを少し再構成します。
ターゲットの存在を必要とする根本的な技術的または論理的な理由はありますか?
boost::filesystem::canonical()つまり、ターゲットが存在しないと、どういうわけか正規形への道を解決できなくなるのでしょうか?そうでない場合、ターゲットの存在を必要としないという点で既存の形式とのみ異なる機能のバリエーションを提案しない技術的または論理的な理由はありますか?
boost::filesystem提案された N4100 への変換 (私が理解しているように)std::experimental::filesystemでは、この制限は十分なcanonical()検討の後に採用されていますか、それとも Boost の定義から「抜け落ちている」だけですか?
編集2：
Boost 1.60が次の関数を提供するようになったことに気付きましたweakly_canonical()。canonical()もしあれば、存在しない p の要素によって。」
編集3：
これについては、に関連してさらに説明std::filesystemします。