From 1d7d63e27c15e6f2b5cb0cd4239fb44801ffbf96 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Wed, 28 Dec 2011 03:40:39 +0100 Subject: [PATCH] document a hack for guessing implementation sizes --- doc/technical/code/darkCorners.txt | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/doc/technical/code/darkCorners.txt b/doc/technical/code/darkCorners.txt index 732c2c9ee..03bd9311c 100644 --- a/doc/technical/code/darkCorners.txt +++ b/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. +