...since I consider that a comparatively safe convenience feature.
Of course we *do perform* a NULL check and throw an exception.
So now the actual casting or conversion functions are designed
to work always on the same level of references or pointers,
which means we can just use the standard conversions of the
language. This has the nice effect of ruling out dangerous
combinations (like taking a L-ref from a R-ref) automatically
(extracted from the git history of file try.cpp, May 2008)
basically this is the draft implementation from which
AccessCasted was extracted. I see two problems
- this version prints from within the access functions
- we do not want the automatic static downcast anymore.
meanwhile, I consider this kind of "do everything for me"
programming style as dangerous. If unchecked donwcasts
are desired, then code them up explicitly
finally got all those copy / assgnment flavours straight.
Still unsolved: unable to instantiate the Variant template
for a type with private assignment operator (like e.g. Time )
The problem is our virtual assignement operator, which forces
instantiation of the implementation (for the VTable), even if
the actual assignment is never invoked.
- we do not want type mutations
- we do not want "empty" records ever
- we do not support "probing" for contents
- visitor style access for generic value handling
After some reconsideration, I decide to stick to the approach with the closures,
but to use a metaprotramming technique to build an inheritance chain.
While I can not decide on the real world impact of storing all those closures,
in theory this approach should enable the compiler to remove all of the
storage overhead. Since, when storing the result into an auto variable
right within scope (as demonstrated in the test), the compiler
sees the concrete type and might be able to boil down the actual
generated virtual function implementations, thereby inlining the
given closures.
Whereas, on the other hand, if we'd go the obvious conventional route
and place the closures into a Map allocated on the stack, I wouldn't
expect the compiler to do data flow analysis to prove this allocation
is not necessary and inline it away.
NOTE: there is now guarantee this inlining trick will ever work.
And, moreover, we don't know anything regarding the runtime effect.
The whole picture is way more involved as it might seem at first sight.
Even if we go the completely conventional route and require every
participating object to supply an implementation of some kind of
"Serializable" interface, we'll end up with a (hand written!)
implementation class for each participating setup, which takes
up space in the code segment of the executable. While the closure
based approach chosen here, consumes data segment (or heap) space
per instance for the functors (or function pointers) representing
the closures, plus code segment space for the closures, but the
latter with a way higher potential for inlining, since the closure
code and the generated virtual functions are necessarily emitted
within the same compilation unit and within a local (inline, not
publickly exposed) scope.
so yes, it is complicated, and inevitably involves three layers
of indirection. The alternative seems to bind the GUI direcly to
the Session interface -- is there a middle gound?
For the messages from GUI to Proc, we have our commands, based
on PlacementRef entities. But for feeding model updates to the
GUI, whatever I consider, I end up either with diff messages or
an synchronised access to Session attributes, which ties the
responsiveness of the GUI to the Builder operation.
- we use a GenNode element
- this holds a polymorphic value known as DataCap
- besides simple attribute values, this may hold collections of GenNode sub elements
- a special kind of GenNode collection, the Record, is used to represent objects
The purpose of this setup is to enable an external model representation
which is only loosely coupled to the interndal data representation
through the exchange of (tree)diff messages
sans the implementation of the index lookup table(s)
The algorithm is KISS, a variant of insertion sort, i.e.
worst time quadratic, but known to perform well on small data sets.
The mere generation of the diff description is O(n log n), since
we do not verify that we can "find" out of order elements. We leave
this to the consumer of the diff, which at this point has to scan
into the rest of the data sequence (leading to quadratic complexity)
finally....
The problem is that the C++ "dependent types" defeat the typical
DSL usage, where you define some helper function in a generic
language setup class and mix this language in as superclass.
This is, C++ requires us to refer explicitly to any dependent type,
since, due to possible template specialisations, the parser
can't know if a given symbol is a inherited type or a field.
As a solution, we place the token constructor functors into a
static struct "token", which allows to write e.g. token.insert(xyz)
As decided in beb57cde
this changeset switches our basic list diff language to work
in the style of an insertion sort. Rather than 'pushing back'
out-of-order elements, we scan and bring forward missing elements.
Later, when passing the original location of the elements
fetched this way, a 'skip' verb will help to clean up
possible leftowers, so implementation is possible
(and indeed acomplished) without shifting any other elements.
we want a simple and straight forward way of defining tokens
of the "diff language". Each token is bound to a specific
handler function in the language interpreter interface.
Problem is that likely we'll get a ListDiffLanguage and a TreeDiffLanguage;
after all, I really don't know yet how far to take this whole
diff representation endeavour...
Basically attempt to represent the individual diff step
as a tuple of "DiffVerb" and reference element.
The meaning of the reference element depends on the actual verb
...first step is to design a generic linearised list diff representation.
Basically just need to pull together the theoretical work of the last weeks.
Next steps will be to extend to typed ordered trees.
Heureka! found out that the C++ standard library exposes a
cross vendor C++ ABI, which amongst others allows to show
object code names and type-IDs in the language-level, human
readable unmangeld form.
Of course, actual application code should not rely on such a
internal representation, yet it is of tremendous help when
writing and debugging unit tests.
Signed-off-by: Ichthyostega <prg@ichthyostega.de>
the idea ist to build some kind of "smart" enum constants,
which allow for double dispatch through a member function pointer,
invoking a virtual function on a common handler interface
Actually I arried at the conclusion, that the *receiving* of
a diff representation is actually a typical double-dispatch situation.
This leads to the attempt to come up with a specialised visitor
as standard pattern to handle and apply a diff. Obviously,
we do not want the classical GoF-Visitor, but (yes, we had
that discussion allready) -- well in terms of runtime cost,
we have to deal with at least two indirections anyway;
so now I'm exploring the idea to implement one of these
indirections through a functor object, which at the same time
acts as "Tag" in the diff representation language (instead
of using an enum as tag)
Uniform sequence at start of source files
- copyright claim
- license
- file comment
- header guard
- lumiera includes
- library / system includes
Lumiera uses Brittish spelling. Add an according note to the styleguide.
- the tests covering threadind support and object monitors
are located in the backend test-library and linked against liblumierabackend.so
- some fundamental facilities of proc-layer moved from the library tree
into the basic components tree, since *testing* them requires at least
to link against liblumieracommon.so
In Clang, static object fields are initialised from top to bottom,
but before any other variables in anoymous namespaces. To the contrary,
GCC evaluates *any* initialisation expression in the translation
unit together from top to bottom. Thus, in the clang generated
code, in two cases the static initialisation could use a not yet
constructed local lib::_Fmt formatter object.
the use of a custom finisihing functor, which is applied
to any generated product. This can be used for registration,
memory management or similar framework aspects
Implement the first simple usage scenario for the
unified MultiFact template, using variadic templates.
NOTE:
- the obvious solution based on std::forward
triggers strange behaviour in GCC-4.7
- the inline lambda in the test case traps the
CLang-3.0 parster with a segfault. Horay!
right now we have to defeat an unfortunate static assertion in
the standard library, which is expected to go away in the future.
We use a hack to hijack the problematic definition with the preprocessor,
which requires our header to be first.
This is a notable difference to the boost or tr1-function objects
we used up to now. Thus the behavour is now straight forward without
any exception. If the function takes an argument by reference,
this is replicated through bind and function expressions
a real fix would be to rewrite the test to collect the retrieved
values and do a structural verification of the results. This
would mean to write a lot of code for such a marginal topic,
which was implemented just for sake of completenes anyway.
Hopefully my lack of "motivation" doesn't backfire eventually ;-)
Conversion means automatic conversion. In our case,
what we need ist the ability to *construct* a bool from
our (function) object -- while functors aren't automatically
convertible to bool. Thus we use one of the new predicates
from <type_traits>
...uncovered by switching to c++11
When invoking an individual test, we used to erase
the 0-th cmdline argument, which happens to be allways
the name of the test being invoked. Yet none of our
tests actually complied to that contract. Rather,
all tests taking arguments access them by 1-based
argument index. Previously, the argument values just
happened to be still in memory at the original location
after erasing the 0st element.
"Fixed" that by changing the contract. Now, the 0th argument
remains in place, but when there are no additional arguments,
the whole cmdline is cleared.
This is messy, but the test runer needs to be rewritten
entirely, the whole API is clumsy and dangerous. Ticket #289
this is rather a workaround.
The problem is a wraparound while calculating the common denominator in
Time rawTime (dirt + frames*F25);
Currently we're using boost_rational<long>, and long is only 32bit
on 32bit platforms. The workaround commited here just avoids
the calculation of the fractional value, and adds 64bit time values
instead. But the real solution would be to use a consistent
approach for dealing with frame counts and frame rates, all
based on 64bit values. See Ticket #939
This is a partial and preliminary fix; we had an occasional
numeric overflow on 32bit platforms in some tests.
The complete fix will be to introduce a typedef and then
rework the relevant APIs (which are preliminary anyway,
thus no urge right now)
- 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 *//**
We don't need this ability and it pushes us into using a
central registry. This solution turned out to be problematic
when loading dynamic libraries (plug-ins).
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.
Clang seems to evaluate the terms of a function call in another order
than GCC -- this uncovered re-entrance errors in some metaprogramming tests,
where we re-used a global formatter object in recursive instantiations.
Compilation with Clang 3.0 (which is available in Debian/stable) fails,
mostly due to some scoping and naming inconsistencies which weren't detected
by GCC. At some instances, Clang seems to have problems to figure out a
perfectly valid type definition; these can be resolved by more explicit
typing (which is preferrable anyway)
using our util::_Fmt front-end helps to reduce the code size,
since all usages rely on a single inclusion of boost::format
including boost::format via header can cause quite some code bloat
NOTE: partial solution, still some further includes to reorganise
...this was quite insidious, but most of the problems
were in the test fixture. Treating the root context
on re-creation is something to be carefull though
While this isn't immediately relevant to the problem at hand,
it looks like a sensible idea to be able to explore
an existing data structure by iterators exposing pointers
(instead of reference wrappers).
Generally speaking, reference wrappers would be preferrable,
but, especially when the data structure relies on STL containers,
the default constructed values for resizing rule out
the standard reference wrapper, which can't be default
constructed. Using a custom variant would be equivalent
to using just a plain pointer (since both can be NULL and can be rebound)
...for the very specific situation when we want
to explore an existing data structure, and the
exploration assumes value semantics.
The workaround then is to use pointers as values.
This test setup is intended to emulate the situation
when adding jobs to the scheduler; thus we should use
an implicit sequence as root element.
I.e. we have to treat a wood, not a single tree
Note: test still fails, since we take a copy
of a Node object somewhere inadvertently
...attempt to build it based on the monadic iterator primitives.
Only problem is: need to find out relation between nodes
after the fact. In the real usage situation, this
is not a problem, since we have a state object
there, which can track the relation as it is established
the buildsystem will now pick up and link
all test cases according to the layer, e.g.
backend tests will automatically be linked
against the backend + library solely.
* tmpbuf got its own implementation files
* Some optimizations on the tmpbuf implementation, handling tiny,
small and huge allocations better.
* tiny allocation smaller than sizeof(void*) are not aligned
* Reduced the ring sizes to 16 (configureable in tmpbuf.h)
This is only the tmpbuf refactoring, fixes following on the next
commits.
test.h introduces a PLANNED_TEST() macro for C code, shows what tests
are provided and so on (the nobug version did that since some time).
test names are now passed as identifers and translated to strings by the
macros.
A lot fixes for existing tests, replace some printfs with ECHO, cosmetics.
one threadpool (sync_many) test is broken and set to PLANNED, this needs
further testsuite support for dispatching output.
add a TEST nobug flag to test.h
* commit '99b5f8':
adapt the Sync template
Add reccondition to threads, make its functionality complete
fix some includes for new mutex/recmutex headers
weed out reccondition bugs/typos
New condition and reccondition implementation
split mutex.h again into mutex.h and recmutex.h
typo fix in mutex.h
rename casing of RecMutex to Recmutex to be consistent
store lumiera_rwlock in sectionlock
store a lumiera_mutex in a sectionlock, looks cleaner
add check to chained locking validating that the parent lock is held
rwlock makeover, locksections etc...
error code changed to LOCK_DESTROY
fix: forgotten backcasts in mutex.h
new mutex and recmutex implementation (breaks sync.hpp for now)
lumiera_error_set() now takes an optional extra string which can be used
to pass context relevant data along. This string gets copied into the
error state so one can easily create it by the tmpbuf_snprintf() facility.
Also a lot of places which define errors get fixed according to this.
