The key trick is to form an expression with the free function, using a declval of the type to probe.
What is somewhat tricky is the fact that functions can be void, so we need just to pick up
the type and use it in another type expression
...still somewhat unsatisfactory, because
- no clear compile error message when invoking pickArg with insufficient arguments
- the default initialisation case in SelectVararg is duplicated and messy
since the adoption of C++11, we gradually transition our metaprogramming helpers
to support and rely on variadic template parameters. For the time being,
we just augment existing facilities when it comes in handy, yet some more
heavyweight lifting and overall clean-up remains to be done eventually.
seems to be impossible to get rid of the intermediary argument repackaging delegate call.
As always the reason is that argument packs are no real first class types
there is the danger to get into building a fully generic solution, which is
- quite hard / challenging
- counterfeits the goal of writing easy-to-read code
This is the very reason why I do not want to use boost::MPL,
because in our usage situation, their abstractions are not worth
the price in terms of hard to read code.
...since there is not any test coverage for this trait, which
turned out to be quite deeply rooted in the system by now and
handles several rather subtle special cases
the usual suspects...
turns out we need specialisations for those too, even while in most cases
those special reference type won't make it far, and just degrade to function pointer
...to not rely on the old-style signature templates anymore,
i.e. get rid of typename FunctionSignature<function<RET(ARGS...)>>
now, most cases just delegate to the "plain signature" case
..otherwise unchanged.
NOTE: we need two variants, since lambdas are always const functions,
while a member pointer to (non)const function would not be captured
by that overload and thus recurse into the main case and fail there
with "has no operator()"
...and move the tail-call of the template instantiation into try.cpp
This experiment clearly shows the discrepancy now:
- binding a member pointer directly into a function object will expand the argument list
- but binding a similar lambda into a function object won't
(it is not necessary due to the context capture)
The result is that we need to drop support for one of those cases,
and it is clear that the member poiter will be the looser...
It is not clear what would be the 'right' way to handle a member pointer to function
within the function-trait _Fun. The existing implementation choose to inject
an additional parameter for the enclosing class ("this"), which seems to collide
with the intention to use this overload with the "decltype trick" to integrate
support for lambdas.
As it turns out, this specific code path of the existing _Fun trait was not
yet used, fortunately, so we're free to search for the proper design here...
...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!
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
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
...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.
- 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
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
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
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
