TODO: the toolfactory needs a redesign anyway,
this was just placeholder code added in a very early
state of the Lumiera project. We have way better memory
managing facilities at hand now
the use of a custom finisihing functor, which is applied
to any generated product. This can be used for registration,
memory management or similar framework aspects
Implement the first simple usage scenario for the
unified MultiFact template, using variadic templates.
NOTE:
- the obvious solution based on std::forward
triggers strange behaviour in GCC-4.7
- the inline lambda in the test case traps the
CLang-3.0 parster with a segfault. Horay!
...but the whole design looks still overengineered. See #388
- should get rid of the explicit specialisation
- always use a function signature and thus have arguments?
- why inheriting from the wrapper?
still puzzled why this instantiation of MultiFact fails to compile with GCC 4.8
so I'm bound to understand why the types involved
need indeed to be are structured the way they are right now.
previous versions used to resolve this ambiguity in favour of a ctor call,
but now the compiler treats such constructs as function definition;
this is reasonable, since C++11 introduced the notion of a "generalised
initialisation", which is always written as a (possibly empty) list
in braces.
In these specific cases here, we just omit the empty parens
Since we have now a generic bridge to supply std::hash functions based on
an exisiting boost::hash function, we removed the explicit std::hash
specialisation for "Placement-ID".
This caused the PlacementIndex implementation to fail at compilation
with a quite obscure error, which in fact seems to be caused by the
absence of any specific specialisation. The symptom is that a iterator
range could not be assigned to the predefined iterator type of
std::unordered_multimap, due to a mismatch in the embedded traits type
__umap_traits<__cache_default<_Key, _Hash>::value>>
While I didn't track down that problem entirely, to verify my hypothesis,
the problem can be avoided by using the default -- which is now to
pick up an existing boost::hash function for this type and use this
to generate the std::hash function.
right now we have to defeat an unfortunate static assertion in
the standard library, which is expected to go away in the future.
We use a hack to hijack the problematic definition with the preprocessor,
which requires our header to be first.
NOTE: this header contains a potentially dangerous, temporary workaround
to defeat the static assertion in the default implementation of std::hash,
as shipped with GCC 4.7.x
This assertion turns out to be detrimental all kinds of metaprogramming
based solutions, since it defeats SFINAE. It is expected to be removed
in GCC 4.8
the rules are:
- our own headers go before any library headers
- all headers need to be spelled relative to include root
- ensure that gtk is always included via gui/gtk-base.hpp
this completes the exploration; we should now be able to use
any type with boost hash support in the std unordered containers
without much ado.
I wasn't able to come up with a completely modular solution, since
the std::hash template has only one template parameter, which
defeats using enable_if. But since we're controling the default
implementation after the Hijacking anyway, we can as well go
ahead directly to forward to an existing boost::hash function
this turns out to be quite tough, since boost::hash
just requires a free function 'hash_value' to be
"somehow" present, which might be just through ADL.
My solution is to inject an fallback declaration of such a function,
but only in the namespace where the trait template is defined.
Hopefully this never interferes with real hash functions defined
for use by boost::hash
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
c++11 uses another hashtable implementation.
This uncovered some poorly written tests, which relied on
objects being returned in a specific order. As far as poissible,
we're using generic query functions now to get our test objects.
But these tests still rely on a specifically crafted test index content,
which as such is acceptable IMHO. The only remaining problem is
that we check the order of generated output in some tests, and this
order is still implementation dependent.
This is a notable difference to the boost or tr1-function objects
we used up to now. Thus the behavour is now straight forward without
any exception. If the function takes an argument by reference,
this is replicated through bind and function expressions
a real fix would be to rewrite the test to collect the retrieved
values and do a structural verification of the results. This
would mean to write a lot of code for such a marginal topic,
which was implemented just for sake of completenes anyway.
Hopefully my lack of "motivation" doesn't backfire eventually ;-)
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>
...uncovered by switching to c++11
When invoking an individual test, we used to erase
the 0-th cmdline argument, which happens to be allways
the name of the test being invoked. Yet none of our
tests actually complied to that contract. Rather,
all tests taking arguments access them by 1-based
argument index. Previously, the argument values just
happened to be still in memory at the original location
after erasing the 0st element.
"Fixed" that by changing the contract. Now, the 0th argument
remains in place, but when there are no additional arguments,
the whole cmdline is cleared.
This is messy, but the test runer needs to be rewritten
entirely, the whole API is clumsy and dangerous. Ticket #289
we still don't check for the precise boost version number in the
SCons configuration. We might do so in future, but for now our
policy is that precise version dependency checking is the business
of the packager (i.e. the debian package). The SCons build just
has to ensure the absolute necessary baseline
* use a development snapshot of lib SigC including the recent C++11 adaptations
* never include whole namespaces. Here we got a clash between std::bind and sigc::bind
* use lambdas
* to make the binding code more readable
* to take the nested invocations apart, which resolves the return type ambiguity
Why GNU extensions? They where on by default previously,
so we're changing nothing besides the C++ standard level.
AFAIK, we're using a GNU extension at one place, and this
could be replaced by 'decltype' now.
In the November developer meeting, Christian and I agreed that
it's best to remove that offending LUID specifications altogether.
Those embedded LUIDs where one of the issues blocking the transition to C++11
