Ichthyostega
26bf32525b
* based on reproducible data in `TestFrame` * using Murmur64A hash-chaining to »mark« with a parameter This emulates the simplest case of 1:1 processing and can also be applied ''in-place''
51 lines
No EOL
2.4 KiB
Text
51 lines
No EOL
2.4 KiB
Text
Dark Corners
|
|
============
|
|
|
|
_this page accounts for some problematic areas, sketchy solutions,
|
|
nonportable hacks, terrorism and other misdemeanour_
|
|
|
|
Library
|
|
-------
|
|
|
|
Binding Placeholders
|
|
~~~~~~~~~~~~~~~~~~~~
|
|
The standard allows function objects to be partially closed; this is achieved by
|
|
marking the remaining, unbound arguments in the call to `std::bind` with some special
|
|
_marker elements_, the ``argument placeholders''. These are predefined within the
|
|
standard library as `std::placeholders::_1` and consecutive, while the _type_ of
|
|
these objects remains _unspecified_ as by the standard. But unfortunately we need
|
|
some augmentation on top of `std::bind` to help with _generic partial application_
|
|
of functions, i.e. we need to close systematically a sequence of arguments, both
|
|
starting from the front or from the back of the argument list. We need this,
|
|
because it is a standard functional programming technique. Consequently
|
|
our helper (`function-closure.hpp`) will build placeholders on its own,
|
|
and it needs to feed _placeholder types_ to the generated binders.
|
|
|
|
Thus we rely on the fact, that the gnu standard library implementation
|
|
has a templated type `std::_Placeholder<i>`
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
Portability
|
|
-----------
|
|
- Linux-only solution to discover the path of the executable: `findExePath` in 'lib/searchpath.hpp'
|
|
- hard-coded usage of `/dev/urandom` (e.g. in 'lib/random.cpp' as spec for the `std::random_device`
|
|
- using the 64bit Murmur-2.64A hash function in '/lib/hash-combine.hpp' |