as it turned out, the solution from yesterday works only with uniform argument lists,
but not with arbitrarily mixed types. Moreover the whole trickery with the
indices was shitty -- better use a predicate decision on template argument level.
This simple solution somehow just didn't occur to me...
...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
some time ago we abandoned our own tuple type in favour of std::tuple
Since then, the helpers and ported utilities provide some generic helpers
to deal with variadic argument sequences, especially to build index sequences,
which in turn can be used to "pick" individual arguments from a variadic parameter pack.
The expectation is for this part of the support library gradually to grow and
in parts to replace the existing type sequence processing helpers. The expectation
is that we'll retain the basic type sequence, lib::meta::Types, but retrofit it
to rely on variadic arguments
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.
basically DiffMessage has a "take everything" ctor, which happens
to match on type DiffMessage itslef, since the latter is obviously
a Lumiera Forward Operator. Unfortunately the compiler now considers
this "take everyting" ctor as copy constructor. Worse even, such a
template generated ctor qualifies as "best match".
The result was, when just returing a DiffMessage by value form a
function, this erroneous "copy" operation was invoked, thus wrapping
the existing implementation into a WrappedLumieraIterator.
The only tangible symptom of this unwanted storage bloat was the fact
that our already materialised diagnostics where seemingly "gone". Indee
they weren't gone for real, just covered up under yet another layer of
DiffMessage wrapping another Lumiera Forward Iterator
by moving, we can avoid the generation of up to 3 additional shared copies
of the DataHandle. The whole invocation now works without touching any shared count
and thus without incurring a memory barrier...
this becomes more relevant now, since the actual MutationMessage iterators
are implemented in terms of a shared_ptr to IterSource. Thus, when building
processing pipelines, we most definitively want to move that smart-ptr into
the destination, since this avoids touching the shared count and thus avoids
generating unnecessary memory barriers.
...allows us to get rid of quite some boost-includes
Incidentally, "our own" implementation is equivalent to both the
boost implementation and the implementation from C++14
It is just a bit more concise to write.
since we do not want to increase the footprint, we're bound to reuse
an existing VTable -- so IterAdapter itself is our only option.
Unfortunately we'll need to pass that through one additional
decoration layer, which is here the iterator; to be able to
add our string conversion there, we need to turn that into
a derived class and add a call to access the underlying
container, which gets us into element type definition mess....
now this highlights the unsettled decision still the more,
as can be seen by all that unnecessary copying. Basically we move the
Diff into the lambda-closure, from there into an anonymous instance,
from there into the embedded Buffer in MutationMessage, which again
just happens to sit in the closure storage when the action is invoked.
And all of this copying just to move the DiffMessage for consumption
into the TreeMutator...
thus by #1066 we should really get rid of the MutationMessage class altogether!
actually I do not know much regarding the actual situation when,
within the Builder run, we're able to detect a change and generate
a diff description. However, as a first step, I'll pick IterSrouce
as a base interface and use a "generation context", which is to be
passed by shared-ptr
again surprising how such fundamental bugs can hide for years...
Here the reason is that IterAdapter leaves the representation of "NIL" to
its instantiation / users; some users (here in for example the ScopedCollection)
can choose to allow for different representations of "NIL", but the comparison
provided by IterAdapter just compares the embedded pos by face value.
seems like most usages will want to expose this kind of diagnostics for unit testing
and in fact the queue or stack nature is the primary nature of this entity,
while iterability comes as additional trait
- concept for a first preliminary implementation of dispatch into the UI thread
- define an integration effort to build a complete working communication chain
...again to make it work with GCC-5,
also to allow more leeway using various compilers
Explanation: we use a helper function to abbreviate the
demangled type names to make diagnostic ouput more readable.
Obviously such a function needs to be adjusted to the
way concrete compilers generate their type output; GCC-5
slightly differs to GCC-4.9 here, so I've made the regular
expressions a bit more flexible
we have a catch-all template operator to get a string converted
or pretty printed output from "any object". Unfortunately
this overload counts equivalent to another overload by
the IO manipulators. Solution is to define both operarators
similar in the first argument, thus turing the overload
for the IO manipulators into the more specific overload
due to the explicitly given second argument
this seems like an obvious functionality and basically harmless,
since commands are designed to be inherently stateful, which is reflected
in all the internal storage holders to expos an assignment operator
(even while the actual implementation is based on placement new instead
of assigning values into the storage, and thus even supports immutable
values). The only possible ramification is that argument values must
be default constructible
in accordance to the design changes concluded yesterday.
- in the standard cases we now check the global registry first
- automatically create anonymous clone copy from global commands
- reorganise code internally to use common tail implementation
