GitHub上のプレビューが壊れていたため、見出し記法のあとにスペースを入れるようにした

cpprefjp/site#396

README.md

@@ -6,13 +6,13 @@ site
 現在、編集環境をGoogle SitesからこちらのGitHubリポジトリに移行する作業を行っています。
 
 
-##編集方法
+## 編集方法
 boostjpの編集方法については、以下のドキュメントを参照してください。
 
 * [boostjpを編集するには](/editors_doc/start_editing.md)
 
 
-##運営者
+## 運営者
 boostjpは、以下のコアメンバが運営を行っています：
 
 * [Akira Takahashi](https://github.com/faithandbrave/)
@@ -22,7 +22,7 @@ boostjpは、以下のコアメンバが運営を行っています：
 * [Akiko Yamanouchi](https://github.com/h-sao)
 
 
-##ライセンスについて
+## ライセンスについて
 本サイトの情報は、[クリエイティブ・コモンズ 表示 3.0 非移植 ライセンス(CC BY)](http://creativecommons.org/licenses/by/3.0/)の下に提供しています。
 
 ![](http://i.creativecommons.org/l/by/3.0/88x31.png)

archive.md

@@ -1,4 +1,4 @@
-#アーカイブ
+# アーカイブ
 
 更新が終了したページの置き場所。更新を再開する場合は、これらのページを移動してください。
 

archive/boost_docs.md

@@ -1,16 +1,16 @@
-#旧Boost日本語化プロジェクト
+# 旧Boost日本語化プロジェクト
 ここには、cppllコミュニティで行われていたBoost翻訳プロジェクトのドキュメントを、移植して残しておく。移植元のドキュメントは、[boostjp/old_boostjp_site](https://github.com/boostjp/old_boostjp_site)リポジトリに、HTMLファイルとして保存してある。
 
 これらのドキュメントはBoost 1.31.0当時のものであり、現在でも有効とは限らないことに注意してほしい。
 
 また、これらのドキュメントは`/archive`以下の置いているため、メンテナンスはされていない。メンテナンスする場合は、そのドキュメントを`/document`以下に移動してメンテナンスしてほしい。
 
-##ドキュメント
+## ドキュメント
 - [ジェネリックプログラミング手法](boost_docs/document/generic_programming.md)
 - [ジェネリックコンポーネントにおける例外安全性](boost_docs/document/generic_exception_safety.md)
 - [エラーと例外のハンドリング](boost_docs/document/error_handling.md)
 
 
-##ライブラリ
+## ライブラリ
 - [各ライブラリの翻訳ドキュメント](boost_docs/libs.md)
 

archive/boost_docs/document/error_handling.md

@@ -1,24 +1,24 @@
-#エラーと例外のハンドリング
+# エラーと例外のハンドリング
 
 - 翻訳元：<http://www.boost.org/community/error_handling.html>
 
 
-##参照
+## 参照
 次の文書は堅牢で汎用的なコンポーネントを書くときのいくつかの問題に対する、 良い手引きである。
 
 - D. Abrahams: ["Exception Safety in Generic Components"(邦訳：「ジェネリックコンポーネントにおける例外安全性」)](generic_exception_safety.md), originally published in [M. Jazayeri, R. Loos, D. Musser (eds.): Generic Programming, Proc. of a Dagstuhl Seminar, Lecture Notes on Computer Science 1766](http://www.springer.de/cgi-bin/search_book.pl?isbn=3-540-41090-2)
 
 
-##ガイドライン
-###いつ例外を使うべきか?
+## ガイドライン
+### いつ例外を使うべきか?
 単純な答えは: 「例外のセマンティクスとパフォーマンスの性質が適していればいつでも」
 
 よく引用されるガイドラインは 「これは例外的な(或いは期待されていない)状況なのか?」 とあなた自身に問うことである。このガイドラインはその問題に対して、 魅力的な響きがするが、通常間違っている。問題はある人間の「例外的」 が、別の人間の 「期待通り」 である、ということである: その述語をあなたが本当に注意深く見るとき、例外的と期待通りの間の区別は消えて無くなり、 ガイドラインはもはやあなたのもとには残らない。 結局、もしエラーの状態をチェックするなら、ある意味であなたはそれが起こるのを期待しているか、 そうでなければそのチェックは全く無駄なコードなのである。
 
 この問題により相応しい問いは: 「ここでスタックを巻き戻したいか?」 ということである。実際に例外を扱うことは、コードの主流を実行するより かなり遅いと考えられるので、あなたは更にこう問うべきである: 「私はここでスタックを巻き戻す余裕があるのか?」 例えば長い計算を行っているデスクトップアプリケーションは、ユーザがキャンセルボタンを押したかどうか、 定期的にチェックするだろう。例外を投げれば、キャンセルは美しく行われる。 一方、この計算の内側のループで例外を投げ、 *扱う* ことはおそらく適していない。 パフォーマンスにおおいに影響するからである。
 
 
-###プログラマのエラーについては?
+### プログラマのエラーについては?
 開発者として、もし私が自分の使っているライブラリの事前条件を違反したなら、 私はスタックを巻き戻したくはない。私が行いたいことは、コアダンプを吐くか、 それと同等のことである。つまり、問題が発見された実際の場所で、 プログラムの状態を調べる方法が欲しいのである。 これは通常、 `assert()` などである。
 
 ほとんどの種類の、クライアントの誤用に耐えうる、 回復力のある API が必要なときもあるだろう。 しかし、このアプローチには通常、大きなコストが伴う。 例えば、これは通常、クライアントが使うオブジェクトそれぞれについて追跡することで、 その妥当性をチェックすることが出来るだろう。 もしその種の保護を行う必要があるなら、通常、単純な API の最も上の層として 提供することができる。もっともこれは、中途半端な方法だということに気づかなければならない。 多くの誤用に - しかし全てではない - 対する回復を約束する API は災いを招く。 クライアントはその保護に頼り、その期待はインタフェースが守らない部分にまでふくらむだろう。