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.
- upgrade the configuration to a current version
- provide a frontpage with cross-links to other documentation
- define a set of modules; relevant classes and files can be
added to these, to create a exploration path for new readers
- fix a lot of errors in documentation comments
- use a custom configuration for the documentation pages
- tweak the navigation, the sections and further arrangements
to make them stand out more prominently, some entity comments
where started with a line of starts. Unfortunately, doxygen
(and javadoc) only recogise comments which are started exactly
with /**
This caused quite some comments to be ignored by doxygen.
Credits to Hendrik Boom for spotting this problem!
A workaround is to end the line of stars with *//**
Clang doesn't allow to declare a private nested class as friend.
This is unfortunate, but likely correct to the letter of the standard.
As a workaround, now we're creating the instances within a static
function of DependencyFactory -- in the end this improves readability
A second issue fixed with this changeset is the scope of the
marker function. Clang is right, this isn't ADL, thus an inline
friend definition is simply not visible outside the class.
lib::Depend<TY> works as drop-in replacement for lib::Singleton<TY>
This changeset removes the convoluted special cases like
SingletonSub and MockInjector.
there is now a mechanism to allow sprcialised queries
to generate this syntactic representation only on demand
The actual concrete representation e.g. for scope queries
still remains TODO, but this won't really change
until we target the integration of a real resoloution engine
while refactoring, I thought it might be a good idea
only to use Query objects. But in this special case,
most often you'd just want to pass in a simple query
with a literal query string. So this convenience shortcut
indeed makes sense.
the rules-based configuration and query system
will be located within the core application,
while the concrete implementation facilities
are expected to reside within the session or
maybe also the GUI.
This is kind of a 'rochade' refactoring to resolve
circular library dependencies and confine the parts
dependant on the session and MObjects to the Proc-Layer
And while we're in the middle of chainsaw surgery,
we'll concentrate further query-based facilities
alongside the config-rules within the App core.
makes the test logs way more readable
Believe me: no one will ever notice a "TODO"
entry in the logs, when it showed up for
more than some months.
Thus I've created some new tickets, mostly
tagged as "QA" and placed the ticket number
at the corresponding locations in the source
