over time, we got quite a jungle with all those
shome-me-the-type-of helper functions.
Reduced and unified all those into
- typeString : a human readable, slightly simplified full type
- typeSymbol : a single word identifier, extracted lexically from the type
note: this changeset causes a lot of tests to break,
since we're using unmangeled type-IDs pretty much everywhere now.
Beore fixing those, I'll have to implement a better simplification
scheme for the "human readable" type names....
...based on all the clean-up and reorganisation done thus far,
we're now able to rebuild the util::str in a more direct and
sane way, and thus to disentangle the header inclusion problem.
due to the new automatic string conversion in operator<<
the representation of objects has changed occasionally.
I've investigated and verified all those incidents.
...other than intended, the bomb did explode on random occasions,
with an probability of about 4% (when rr >= 96).
Btw, there was also the mistake to throw an heap allocated
object by pointer. Damn Java habits.
- remove unnecessary includes
- expunge all remaining usages of boost::format
- able to leave out the expliti string(elm) in output
- drop various operator<<, since we're now picking up
custom string conversions automatically
- delete diagnostics headers, which are now largely superfluous
- use newer helper functions occasionally
I didn't blindly change any usage of <iostream> though;
sometimes, just using the output streams right away
seems adequate.
the usual drill...
only when wrapped into a factory function, RAII is really
airtight, even when used from within expression evaluation.
Thanks C++11 we're now able to provide such en passant
our lib::P smart-pointer is built on top of std::shared_ptr,
while additionally delegating comparisons to the pointee.
In a similar vein, I've now added a custom string conversion,
delegating to the pointee, with a type-string as fallback.
Together with the built-in string conversion for output streams,
we should now be able to remove most of the explicit string
conversions and calls to util::str in all of our test code.
This removes the last roadblock towards disentangling the
pretty-printing header includes, which in turn should allow
us to remove any conditional code in the built-in string
conversion of GenNode, Variant and the like. Which basically
was the objective for ticket #985
use a shortened display, showing only the last 4 bytes for diagnostics
since we're typically only interested in spotting "same" and "different",
while the full memory address is irrelevant
provide a generic overload for the stream inserter operator<<
to use custom string conversions when applicable.
The overload will be disabled when a direct lexical conversion
is possible (which means, we can expect the output stream to
know allready how to print those values, like e.g. all kinds
of numbers).
Additionally, we provide a pretty-printing mechansim for pointers,
to show the address and possibly invoke a custom string conversion
on the pointee
No more fiddling with printf just to show a number reliably!
simple functions to pretty-print addresses,
doubles and floats (fixed-point, with rounding).
Also make all these basic formatting helpers noexcept
we need this to branch into lexical conversion, which
should always take precedence over a string conversion.
The existing solution overlooked both the conversion paths
for char*, as well as the fact that chars and c-strings
can be handled directly (pass-through) by lexical conversion
- simple function to pick up the mangled type
- pretty-printing is implemented in format-obj.cpp
- also move the demangleCxx()-Function to that location,
it starts to be used for real, outside the test framework
our minimal compiler requirement is gcc-4.9 since the
transition to Debian/Jessie as reference system.
gcc-4.9 is known to treat SFINAE on private fields properly
this is a stripped-down and very leightweight variant
of the well-known enable_if metaprogramming trick.
Providing this standard variant in a header with minimal
dependencies will allow us to phase out boost inclusions
from many further headers. As a plus, our own variant
is written such as to be more conciese in usage
(no "typename" and no acces of an embedded "::type" menber)
this includes a reorganisation concept for the header includes,
a minimal version (with minimal include dependencies), and
a generic ostream inserter operator<<
...and learned a lot about the new type_traits on the way.
As it seems, it is not possible to get a clean error message
when passing an "object" with no custom string conversion;
instead, some overload for an rvalue-ostream kicks in.
probably I'll go for shoing a type string in these cases
now we use boost::format through our own front-end util::_Fmt
solely, which both helps to reduce compilation time and code size,
and gives us a direct string conversion, which automatically
uses any custom operator string() available on arguments.
While desirable as such, I did this conversion now, since
it allows us to get rid of boost::str, which in turn helps
to drill down any remaning uses of our own util::str
the fixed version is actually more permissive,
insofar it matches any type of event, when ID = classifier
(or alternatively it matches events with type = classifier)
our formatting helper for diagnostics output,
which is primarily used in the unit-tests,
first tries to invoke a custom string conversion.
If that is not possible, it falls back to printing
the demangled type name of the object in question.
With just a minor change we're able to evaluate RTTI here
and print the actual type name, instead of the static
supertype the compiler sees on invocation. We just rely
on the typeid(obj) built-in function.
The only catch is we have to strip the " const*" suffix
(and no, it is not possible to do that on metaprogramming
level, due to the special situation where we have a void*)
This also prompted me to write some util functions for
this often encountered task to check / remove a prefix or suffix
Hopefully I've got those functions correct and safe....
...this is necessary whenever the mocked facility covered
by log matching is managed automatically as singleton,
because then other test cases will leave garbage
in the log
this test is intended as counterpart to
AbstractTangible_test::verify_mockManipulation()
It creates a mock element and verifies bidirectional
connnectivity to the UI-Bus
I worked under the erroneous assumption, that Doxygen
will use its internal entity-IDs as the link-IDs when
generating mardown-links. Yes, this seemed logical and
this would be the way I'd implement it....
But seemingly, Doxygen is not so consistent when it
comes to questions of syntax. The same holds true for
markdown, which lacking a coherent definition anyway.
Another problem is that Doxygen's auto-link generation
frequently fails, for reasons not yet clear to me.
Sometimes it seems to be necessary to give it a nudge
by including the \ref command. While I'm not willing
to go into focussed invstigation of Doxygen syntax
right now, at least I've done a search-and-replace
to remove the malformed links I've written the
last days
the initial draft of this concept is in place now, and
the first round of unit tests pass. I've got some understanding
of the purpose of the interactions and involved elements
and I'm confident this design is evolving in a sane way.
Note: extensive documentation is in the TiddlyWiki,
here I've just pasted and reworded some paragraphs from there
and integrated them into the Doxygen docs
the "log joining" functionality was already implemented
and covered with the generic event log facility, but this test
here was drafted even before that, meaning that the semantics
of matchingn on the log, especially on events, as been
implemented slightly different than planned
Explanation: sigC++ was already linked as transitive dependency
from gtkmm, since it is used for the "signal-slot" system wihin GTK.
But now we want to use sigC++ itself from our generic UI-Backbone,
so we need to pick up the additional compiler and linker flags
and use them when building the relevant parts of both the application
and the test suite
