start a systematic research about the coexistence of
std::hash and boost::hash. The goal is to build an
automatic bridge function -- but this is hampered by
the unfortunate standard implementation of std::hash
Since meanwhile even the GCC people seem to have realized
this wasn't a good idea, I am geared towards using a hack
to work around this problem, which can be expected to go
away with GCC 4.8.x
A possible idea how to construct such a workaround is
http://stackoverflow.com/questions/12753997/check-if-type-is-hashable
I start this investigation by defining two custom types,
each with his own extension point for hashing. The goal
would then be to use both in a standard hashtable container.
note down some results found out during the C++11 transition.
There is now a clear distinction between automatic type conversion
and the ability to construct a new instance
Conversion means automatic conversion. In our case,
what we need ist the ability to *construct* a bool from
our (function) object -- while functors aren't automatically
convertible to bool. Thus we use one of the new predicates
from <type_traits>
this is really creepy: the same(!) instance of the singleton factory
sees different addresses of the class static variable, depending on
the compilation unit.
Please note that the type of the concrete factory function is *erased*
when exiting the constructor function of ConfigurableHolder
basically this reproduces the problem in a simplified setup.
Especially note that we're going through a single instance of the factory,
yet still this single instance 'sees' two different locations of the
class static variable
...but still dynamically linking against the core lib
But the actual template instantiations happen now within the two
compilation units, which are linked statically.
When looking into the symbol table, we can see that the static
field is emitted two times
readelf -W target/clang-static-init -s | c++filt |less
Observations:
- the initial observation was that we get two instances of the config rules service
- obviously this it is *not* the initialisation of a static variable accessed from
multiple compilation units. But the access from two compilation units is crucial
- we can exclude the effect of all other initialisation. It *is* in SingletonSubclass
- we can exclude the effect of dynamic linking. Even two translation units
linked statically exhibit the same problem
rebuild this test case in the research area, to be able to verify with various compilers
