Trying to compile with `-DUSE_UNORDERED_MAP` produces lots of compiler errors
like these, because of missing `std::hash` specializations.
Also, `#define unordered_map map` is just evil!
```
./nonisotropic.cpp:875:36: note: in instantiation of template class 'std::__1::unordered_map<hr::nilv::mvec, hr::heptagon *,
std::__1::hash<hr::nilv::mvec>, std::__1::equal_to<hr::nilv::mvec>, std::__1::allocator<std::__1::pair<const hr::nilv::mvec, hr::heptagon
*> > >' requested here
unordered_map<mvec, heptagon*> at;
^
./nonisotropic.cpp:239:58: note: in instantiation of template class 'std::__1::unordered_map<std::__1::pair<hr::heptagon *, hr::heptagon *>,
hr::heptagon *, std::__1::hash<std::__1::pair<hr::heptagon *, hr::heptagon *> >, std::__1::equal_to<std::__1::pair<hr::heptagon *,
hr::heptagon *> >, std::__1::allocator<std::__1::pair<const std::__1::pair<hr::heptagon *, hr::heptagon *>, hr::heptagon *> > >'
requested here
unordered_map<pair<heptagon*, heptagon*>, heptagon*> at;
^
./nonisotropic.cpp:457:49: error: no matching member function for call to 'iadj'
while(h1->distance < h2->distance) back = iadj(h2, down) * back, h2 = h2->cmove(down);
^~~~
cell.cpp:42:15: note: candidate function not viable: no known conversion from 'hr::sn::hrmap_solnih' to 'hr::hrmap' for object argument
transmatrix iadj(heptagon *h, int d) {
^
cell.cpp:41:22: note: candidate function not viable: no known conversion from 'hr::sn::hrmap_solnih' to 'hr::hrmap' for object argument
struct transmatrix iadj(cell *c, int i) { cell *c1 = c->cmove(i); return adj(c1, c->c.spin(i)); }
^
```
- The phrase `#ifdef CAP_` should never appear anywhere.
- The phrase `#ifndef CAP_` should appear only in sysconfig.h.
- The phrases `#if CAP_` and `#if !CAP_` may appear wherever,
as long as "sysconfig.h" is included first.
The rules for `CAP_FOO` equally apply to `ISFOO`.
There are many one-off macros still tested with `#ifdef`,
including `HAVE_ACHIEVEMENTS`, `PRINT_ACHIEVEMENTS`,
`FAKEWEB`, `FAKE_SDL`, `EASY`, and `WHATEVER`. I don't
have much grasp on what these are used for or how they're
configured, so I'm leaving them alone.
I'm sure this causes massive merge-conflicts in the non-public code,
but I think it'd be a good idea, if only to avoid confusion between
e.g. `clearMemory` and the-variable-formerly-known-as `clearmemory`.
