#18 でcmake対応したのに、CIでそれを使わなかったらメンテされていないビルド手順になってしまい、実質死んでしまう。

MersenneTwister32bit.hpp には複数の static な変数がありますが、これらは inline 関数内で使用されています。
このため、複数の翻訳単位からインクルードすると未定義動作となってしまいます。
（正確には、これらの inline 関数を複数の翻訳単位から使用すると未定義動作となる）

解決方法としては、以下のいずれかになると思います。

1. 複数の翻訳単位から使用することを諦めて、複数の翻訳単位からのインクルードを禁止する。
2. C++17 以降のみ対応として、変数を inline にする。
3. static 変数を諦めて、inline 関数内の static 変数にする。

./MSVC以下がmasterから消え去ったらPull Requestを投げつける

せっかく #18 でcmakeに対応したので、まだ単体テストはないけど、CIでビルドができることを保証したい。

以前某中３女子に質問をしたことがあって、

https://gcc.gnu.org/ml/libstdc++/2012-10/msg00120.html

diff --git a/libstdc++-v3/include/std/chrono b/libstdc++-v3/include/std/chrono
index 209f395..d920a7d 100644
--- a/libstdc++-v3/include/std/chrono
+++ b/libstdc++-v3/include/std/chrono
@@ -250,7 +250,10 @@ _GLIBCXX_END_NAMESPACE_VERSION
    // 20.11.5.1 construction / copy / destroy
    constexpr duration() = default;

-   constexpr duration(const duration&) = default;
+   // NB: Make constexpr implicit. This cannot be explicitly
+   // constexpr, as any UDT that is not a literal type with a
+   // constexpr copy constructor will be ill-formed.
+   duration(const duration&) = default;

    template<typename _Rep2, typename = typename
           enable_if<is_convertible<_Rep2, rep>::value

という変更がどういう意味かを問い合わせたことがありました。

@yumetodo 直訳：暗黙にconstexpr指定される。非リテラル型な任意のUDT(User-Defined Type)に対して、constexprコピーコンストラクタはill-formedになるため、明示的にconstexpr指定すべきでない。

— 狂える中３女子ボレロ村上／陶芸C++er (@bolero_MURAKAMI) 2016年3月14日

@yumetodo つまり、duration<Rep> の Rep は非リテラル型なユーザ定義型である可能性があるため、明示的にconstexpr指定しないようにする変更。Rep がリテラル型である場合、トリビアルコピーコンストラクタは暗黙にconstexpr指定される。

— 狂える中３女子ボレロ村上／陶芸C++er (@bolero_MURAKAMI) 2016年3月14日

と回答していただきました。

さて、例えば

		template<typename Int_>
		struct Coordinate1Dimensional {
			Int_ x{};
			constexpr Coordinate1Dimensional() = default;
			constexpr Coordinate1Dimensional(const Int_& x_) noexcept :x(x_) {};
		};

をみると、上と全く同じ状況であることがわかります。

サポートされる Matrix の形について質問があります。
Matrix は完全に四角形のみサポートされるのでしょうか？
それとも、行によって長さが異なる形もサポートされるのでしょうか？

/Sample/DTL/Storage以下の全ファイルについて

#include <Dungeon/ImageWrite.hpp>

とあるが

#include <DTL/ImageWrite.hpp>

ではないか？

#if defined(_MSVC_LANG) //C++17 use nodiscard
#if (_MSVC_LANG >= 201703L)
			[[nodiscard]]
#endif
#elif defined(__cplusplus)
#if (__cplusplus >= 201703L)
			[[nodiscard]]
#endif
#endif

という記述が多すぎてコードの見通しが悪くなっている。
以下のようなファイルにマクロ定義を用意してそれを使うべき。

// Macros/attribute/nodiscard.hpp
#ifndef INCLUDED_DUNGEON_TEMPLATE_LIBRARY_MACROS_NODISCARD_HPP
#define INCLUDED_DUNGEON_TEMPLATE_LIBRARY_MACROS_NODISCARD_HPP

#if __has_cpp_attribute(nodiscard)
#define DTL_NODISCARD [[nodiscard]]
#elif __has_cpp_attribute(gnu::warn_unused_result)
#define DTL_NODISCARD [[gnu::warn_unused_result]]
#else
#define DTL_NODISCARD
#endif

#endif

#21 でも一回指摘したのですが、まだあったようです。

https://github.com/Kasugaccho/DungeonTemplateLibrary/blob/53065f516678db545264bd960f81658a4d5ab174/include/DTL/Range/BasicRect.hpp#L67

つ～か #33 の継承ctor周りが通らない原因になってたりとか、もしかしてしませんか？(未検証
ちがったぽい

clang++-8 -std=c++17 -Wall -Wextraでコンパイルすると大量のunused parameter警告が出る。
修正すべきかもしれない。

問題

/Sample/DTL/Storage/FileMD.cppは

dtl::storage::FileMD<shape_t>("file_sample.txt").write(matrix);

のように書かれています。名前的にMarkdownじゃないかとおもうのですが、すると拡張子は.txtではなく.mdが妥当ではないでしょうか？

動機

cmake からビルドしたサンプルを走らせるときに、実行前にこれで生成するファイル名を削除するようにする予定である ( #15 ) 。この際に/Sample/DTL/Storage/FileMD.cppだけコンパイルするファイル名(file[A-Z]+.cpp)のパターンに引っかからない拡張子が採用されている。例外処理を書くのがだるいので差し障りがなければこっちを書き換えて対処したい

件のUE4対応のときに、開発ブランチとリリースブランチが別れておらず、少々しんどい思いをしたので、最低限ブランチを分けてほしい（タグ付けはしているようですが）

MersenneTwister32bit.hpp に乱数エンジンが提供されていますが、こちらのクラスに seed sequence を渡すことができません。
メルセンヌツイスターの内部状態は非常に大きいため、seed に単一の整数のみしか渡せないのはちょっと残念です。

http://www.pcg-random.org/posts/cpp-seeding-surprises.html

ちなみに、std::random_device を std::seed_seq で使用する例がこちらに載っています。
https://codereview.stackexchange.com/questions/109260/seed-stdmt19937-from-stdrandom-device