https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56402
The lambda definition captures the this pointer,
but the ctor of the lamda does not initialise this capture.
In our case, we're lucky, as we don't use the "this" pointer;
otherwise, we'd get a crash a runtime.
Fixed since GCC-4.7.3 --> it's *really* time to upgrade to Debian/Jessie
the object VTable is typically emitted when the compiler
encounters the first non-static non-inline function of
the class or a derived class.
Sometimes this happens within the wrong library and so
the compiler needs a nudge to emit those infrastructure functions.
But in most cases this works out of the box and need no further
magic incanctations, which might have a downside.
Especially because also a non-inline dtor does incur a call overhead,
whereas an inline dtor can be trivially elided.
after sleeping a night over this, it seems obvios
that we do not want to start the build proces "implicitly",
starting from a Record<GenNode>. Rather, we always want
the user to plant a dedicated Mutator object, which then
can remain noncopyable and is passed by reference through
the whole builder chain. Movin innards of *this object*
are moved away a the end of the chain does not pose much risk.
especially I've now decided how to handle const-ness:
We're open to all forms of const-ness, the actual usage decides.
const GenNode will only expose a const& to the data values
still TODO is the object builder notation for diff::Record
forwarding equality to the embedded EntryID
Basically, two GenNodes are equal when they have the same "identity"
Ironically, this is the usual twist with database entities
on a second thought, this "workaround" does not look so bad,
due to the C++11 feature to request the default implementation explicitly.
Maybe we'll never need a generic solution for these cases
I decided to allow for an 'unbound' reference to allow
default construction of elements involving record references.
I am aware of the implications, but I place the focus
on the value nature of GenNode elements; the RecordRef
was introduced only as a means to cary out diff comparisons
and similar computations.
basically this is the well known problem #587
Just it became more pressing with the Upgrade to Jessie and Boost 1.55
So I've pulled off the well known "Knuth trick" to spread the
input data more evenly within the hash domain.
And voilà: now we're able to use 100000 number suffixes without collision
- move the santitise operation up into EntryID's ctor
- turn the recast() operation into a real in-place cast
these changes should be transparent to the existing usages
of EntryID (within the asset framework), but allow for use
as attribute name holder in GenNode, since we're now able
to feed existing name/ID values directly into the ctor
of BareEntryID, without any spurious santitise operation.
this was introduced into namespace mobject and spread from there.
Since the habit is to use more specific typedefs like PClip,
it is preferrable to spell out the full namespace
using the struct-scheme.hpp and the requirements for
EntryID as a guideline. The goal is to move EntryID
over into the support lib, which means we need to get rid
of all direct proc::asset dependencies. Thus, these generic
ID functions shall form a baseline implementation, while
asset::Struct may provide the previously used implementation
through specialisation -- so the behaviour of EntryID will
not change for the structural assets, but we'll get a more
sane and readable default implementation for all other types.
these speical reference-flavours of a GenNode are built
to stand-in for a full fledged "object" GenNode.
The purpose is to be able to handle sub-trees of objects
efficiently in comparisions and processing.
This is just a draft for now -- kindof a by-catch, since it is
chep to build that DSL on top of the Rec::Mutator.
This DSL could be of value later, when it comes to define
some configuration data inline, in a copact and clear fashion,
without the need to use a bridge to/from JSON
I had added this variation just to check compilation and
forgot to revert ist. Of course, we do *not* want to move
the inwards of our Mutator in the test. Rather, we want
to draw a copy from the mutated state
for the purpose of working out the inner logic, I frequently use the
help of a mindmap -- so why not commiting this alongside? For sure,
it is preliminary and the worked out concepts will be cast in code
and documented on the website. Yet the thought-process leading to
these decisions might be of some interest, at least for myself.
- can build from the supported value types
- is optionally named
- is copyable value, but only assignable within one payload type
- is recursive, for object / tree representation
before engaging into the implementation of lib::Record,
I prefer to conduct a round of planning, to get a clearer
view about the requirements we'll meet when extending
our existing list diff to tree structures
Initially, I considered to build an index table like
collection of ordered attributes. But since our actual
use case is Record<GenNode>, this was ruled out in favour
of just a vector<GenNode>, where the keys are embedded
right within the nameID-Field of GenNode.
A decisive factor was the observation, that this design
is basically forced to encode the attribute keys somehow
into the attribute values, because otherwise the whole
collection like initialisation and iteration would break
down. Thus, a fully generic implementation is not possible,
and a pseudo generic implementation just for the purpose of
writing unit tests would be overkill.
Basically this decision means that Record requires an
explicit specialisation to implement the attribute-key
binding for each value type to use.
Ouch!
Why does C++ lack the most basic everyday stuff?
It needn't be performant. It needn't support some fancy
higher order container. Just join the f***ing strings.
use Bosst?? -- OMG!! pulls in half the metra programming library
and tries to work on any concievable range like object. Just
somehow our Lumiera Forward Iterators aren't "range-like" enough
for boost's taste.
Thus let's code up that fucking for-loop ourselves, once and forever.
This is kind of the logic consequence, since we consider our
functional iterator concept still superior and will continue
to rely on it.
For some time now, I've considered to build a generic bridge
function, to use enable_if and metaprogramming to figure out
if some type is a "Lumiera Forward Iterator" automatically.
But since our concept is to some degree a contract regarding
semantics, which never can be captured by any kind of introspection,
such a bridge implementation would be rather heuristic and
bears the danger to trigger on types actually not intended
as iterator at all. So I consider such a solution as dangerous
and we'll settle with just supplying the necessary bridge
functions as free functions injected for ADL on a case by case base
this was spotted by a new GCC warning -Wunused-function
and I must admit, GCC is right here: an externally not visible
function in an anonymous namespace is not what I'd expect to be
picked up by ADL. It is rather weird that the metaprogramming
trait worked at all.
Note that the function is intentionally declared only, never defined.
We want a linker error in case boost::hash ever attempts to
use this 'deliberately ill-definded' catch-all.
I'd never imagine that this superficial draft will sit there
for 5+ years without me getting any chance to continue with that topic.
this is so saddening, so I turned off the warning :-/
the valgrind memcheck got more and more flooded with
"possibly lost" memory blocks allocated by GLib and friends.
Linking the vgsuppression binary in the same way than the
testsuite helps us getting ahead of all that noise
Incidentally, we need to rearrange the build dependency tree
here; previously we made the testsuite depend on vgsuppression,
to ensure the latter gets recompiled prior to running tests;
now vgsuppression itself depends on all the test libraries,
so we rather need to make it direcly a prerequisite target
of running the testsuite (this approach is not precisely
correct in a logical sense, yet helps us to get it
recompiled when needed)
this is strange; we need to crank up the VSize to 6 GiB
to get the 5 massively multithreaded tests to run.
I checked those tests with valgrind and can not see
any such huge allocation
