document a hack for guessing implementation sizes

doc/technical/code/darkCorners.txt

@@ -33,3 +33,22 @@ unable to pinpoint _equivalence_, e.g. functors bound to the same function with
 the same arguments through separate but otherwise identical invocations of +bind+.
 Besides, should boost or the standard library implementors eventually change the
 implementation, this workaround will break.
+
+
+Size of standard library facilities
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Sometimes we need to know the size of an STL or Boost class, but can't afford
+to include the header and just write a `sizeof()`. Because including some of those
+headers incurs quite some price in terms of compilation time and even size of the
+debug executable.
+
+Obviously, a simple solution would be to measure those sizes and hardcode them.
+But what about portability? To get out of that dilemma, I created a traits class
+which mimics the implementation memory layout of those facilities in question,
+simplified as much as possible. As long as the GNU libstdc++ or Boost don't
+change their implementation layout, this give us precise and fast size bounds.
+
+When relying on that hack, we should make sure always to place some kind of
+STATIC_ASSERT into the corresponding implementation files to ensure the real
+facilites actually _do fit_ into the guessed storage dimensions.
+