without that check, in theory our test runner will tolerate
a non-zero return value, like throwing or failing an assert,
which is not what we want....
guess these happenend to get in by forgetting to
add this check when switching a test from PLANNED to TEST
since this is a quick-n-dirty workariound, until we're using GCC-5,
I'll err for the simple and safe side and disallow any conversion
from LuidH do some algebraic data type. The problem arises,
sincd LuidH defines a conversion to size_t, which depends
on the platform. So, without checking the actual NumericLimits,
there is no way we can allow a conversion to size_t in a
hard wired way, while disallowing a narrowing conversion
to 32bit unsigned int on 64bit platforms.
And in the end, we don't want conversions from LUID to
numeric values to happen automatically anyway. But of
course we *do* want automatic promotion from a LuidH
to a PlacementRef...
...to avoid warnings when deriving a publicly visible type
from that interface. Newer GCC and CLang versions emit
warnings when details from an anonymous implementation
namespace will leak into type signatures visible outside
the translation unit. In this case here, it's the VTable.
...used in function-closure.hpp to fabricate an argument tuple
for std::bind, for partially closing some function.
This is an attempt to rewrite this somewhat convoluted helper
in a way to fit in with the tuple element picking mechanism
just defined here. Not sure if it's better readable now;
at least it is significantly shorter and omits some
partial specicalisations
because this element picking mechanism for tuples
looks like an instance of something generic.
At least I've written almost the same just some days ago
for the revised version of function-closure, where the
task was to replace a stretch of type arguments in
a given tuple type with a stretch of placeholder types
and then to build a modified ctor, which just fills
in the remaining arguments, while default constructing
the placeholder types. And if we look into the GNU
implementation of std::bind, they're using a similar
concept (with the difference that they're building
a functor object, where we use a type converter)
This refactoring also integrates some generally useful
bits into our standard metaprogramming helper collection
as it turns out, this is a Bug in GCC 4.9 (resolved in 5.x)
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63723
Problem is, GCC emits a warning on narrowing conversions,
while the standard actually disallows them when building
objects from brace-enclosed initialisers.
Unfortunately GCC also emits such a warning from within
a SFINAE context, instead of letting those spurious dangerous
cases fail. So we end up with additional visitor double dispatch
paths, and a lot of additional warnings.
Temporary solution is to hack a custom trait, which
explicitly declares some conversions paths as "narrowing".
Probably this can be implemented in a way more intelligent
way (using std::numeric_limits), but this doesn't seem
worth the effort, since the problem will go away through
compiler evolution eventually.
now we're able to construct suitable parameter values from the
arguments passed embedded in the GenNodes, as is demonstrated with the
EntryID<long> constructed from an ID-string. We really need a full-blown
double-dispatch, since the content type of the concrete GenNode is only
known at runtime (encoded in the RTTI)
There is still the problem with generating some spurions additional
conversion pathes, some of which are narrowing (and thus dangerous).
The copiler emits several warnings here, and all of them are justified.
E.g. it would be possible to pass an int64_t in the GenNode and initialise
a short from it. This might be convenient at times, but I tend rather to
be prohibitive here and thus consider to built in distinct limitations
on the allowed conversions.
working with those variadic index sequences is quite nasty!
Seemingly you'd always need a 2-step type rebinding,
tried several hours now to avoid that, sorry.
What still needs to be settled is the actual problem
of type conversions; we do not want to be confined
just to the small selection of types allowed within
GenNode, rather we want automatic type promotion
when it comes to extracting values into ctor args!
this was a classical example of a muddled and messed-up design,
driven just by the fact that I wanted to "spare" some functions,
with the net effect of writing more functions, plus a proxy class
plus create a lot of confusion for the reader.
This was easy to resolve though, once I resorted to the
general adivice to make public interface methods final,
make the extension ponts protected and never
to chain two extension points
based on the previous experiments, this adds a fake operation
and a definition frame to hook this operation as pseudo Proc-Layer command
WIP: the invocation itself is not yet implemented.
We need to build a custom invocation pattern for that,
in order to be able to capture the instance-ID of the command
on invocation
NOTE: also, because of #989, we can not bind a time value for this test
not sure yet if any of this works, because the
technicalities of dealing with variadic types are
quite different to our LISP-style typelist processing.
The good news is that with variadic templates it is
indeed possible, to supply dynamically picked arguments
to another function taking arbitrary arguments.
This all relies on the feature to unpack argument packs,
and, more specifically, about the possiblity to "wrap"
this unpacking around interspersed function call syntax
template<size_t...i>
Xyz
do_something(MyTuple myTuple)
{
return Xyz (std::get<i> (myTuple) ... );
}
Here the '...' will be applied to the i... and then
the whole std::get-construct will be wrapped around
each element. Mind bogging, but very powerful
we made double use of our Tuple type, not only as a
generic record, but also as a metaprogramming helper.
This changeset replaces these helpers with other
metafunctions available for our typelists or type sequences
(with the exception of code directly related to Tuple itself,
since the intention is to delete this code alltogether shortly)
there was a muddeled mix of type lists and type sequences,
and both where used for processing. Probably the origin
of that confusion was the design of our own Tuple class,
which is implemented based on typelists but accepts a
type sequence at the front-end. From there, a confusing
pattern of equivalence between lists and sequences emerged,
leading to several functions accepting "anything".
This misdesign is not eradicated yet, but in this specific
instance here, has cost me several hours to pinpoint a bug
introduced while refactoring.
See also #967 and #301
This definition -- together with the already existing specialisation
in typeseq-util, allows always to rebind from a given type-list back
to the corresponding type-sequence, by accessing the type member `Seq`
yeah! it works.
some problems though.
- problem-A : reference arguments
* we're storing the parameters as-is
* for not-yet-bound commands we need to store default constructed values
* together this means we can not handle reference arguments
- problem-B : noncopyable arguments
* especially our Time values are noncopyable.
* this is going to become a huge problem for sure!
this pinpoints a compatibility problem:
our lib::meta::Types<...> type sequence is not compatible
with variadic template parameters, since it uses a fixed
list of NullType default arguments to absorb the variable
number of types.
--> TODO: switch lib::meta::Types to variadic arguments!
...and this is cool, since our command framework
already provides a nice type constructor / rebinding template,
so it's easy to pick up just some arbitrary function signature
and fabricate the corresponding "capture" and "undo" signatures.
Starting from there, we can construct std::function objects
with those specifically tailored signatures, and then bind
the actual variadic functions to these.
Bottom line is: it seems feasible to create a variadic
handler function, and then to emulate command invocations
through this function. For one this allows us to build
a debugging facility, and besides that it shows a path
how to solve the other binding problem GenNode -> command
...which causes problems when a preceding include
has already dragged in <functional>
the actual problem is the std::hash hack, which probably
is even no longer possible and could be removed (but
I don't have the time to investigate this somewhat
tricky topic right now)
To prevent this confusing situation, I'm adding the
include of "lib/symbol.hpp", to ensure we do have
the actual definitions of string and Literal,
which trait.hpp just declares forward.
An note, lib/symbol.hpp also includes hash-standard.hpp
first, so we avoid triggering problematic situation
from a header (format-cout.hpp), which is pervasively used
all over the place....
basically this comes down to provide some convenience fixture
within the test::Nexus, which automatically generates and wires
mock commands.
Not sure if this is even possible to the extent envisioned here
since our test.sh runner can be used to verify the
expected output printed by tests, working with these
output transcripts of larger tests can be hard at times.
These separators help to find who produced which output
and they prevent a regexp match to grep beyond the feed
of a single function (which can be a common problem
when using the self-diagnostic output of the facility
currently in test, which obviously will be similar
on any data printed.
First part is to define the steps (the protocol) at the
model element level, which gets a command prepared and invoked.
Test fails still, because there is no actual argument binding
invoked in the TestNexus
we deleted an object on the heap,
and afterwards re-accessed the memory through the
dangling pointer to verify the deletion actually happened.
This works most of the time, unless the memory manager decides
to map that page differently -- in which case we just hit
random memory contents.
A better idea is thus to place this TestFrame object
into a statically allocated buffer and invoke the dtor
explicitly. This allows us to conduct the test reliably.
- replace remaining usages of typeid(T).name()
- add another type simplification to handle the STL map allocator
- clean-up usage in lib/format-string
- complete the unit tests
- fix some more bugs
This clean-up action for Ticket #985 started out as search
for a lightweight generic solution. What is left from this
search now, after including the actual utility code into
our support library, might serve to document this new
feature for later referral
quite sure I never really meant to do that, just, at that time,
it seemed logical to treat Placement as yet another smart-ptr.
But in the light of what crucial entity Placement became meanwhile,
I can't imagine a single case where anyone wants to wrap away a
placement as if it was some shrink-wrap
turns out this is a tricky situation.
We want to accept pretty mutch everything, yet we want to get a grip
on anything object-like, so to reveal available RTTI information.
Now, given the way C++ template substitution works, the 'TY const&' overload
wins with only a few exceptions. The reason is, C++ invokes most functions
passing the concrete argument as reference, unless this is not possible,
because the concrete artument is a rvalue. The automatic reduction of
reference expressions does the rest. Consequently the overload with 'const&'
turns out to be the best match even when we invoke the function with a
pointer expression, which would then be made into a pointer-to-a pointer
by our forward call.
There are two remedies for this dilemma:
- make the second overload just typeStr (TY&)
- explicitly remove the second overload for pointers
The first solution unfortunately would rule out passing of anonymous
objects like concatenated strings; in fact it would rule out passing
rvalues as such. While the second solution, chosen here, works really
for everything, and also has the nice side effect of stripping away
any const, pointer and reference adornements elegantly before we
even start to analyse the type.
The only downside of this solution is that it looks intimidating
to the casual reader. Well, I'd say, get used to it.
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.
