WIP place a ref-count into the result iterator

This commit is contained in:
Fischlurch 2009-10-25 16:18:53 +01:00
parent eb2d309601
commit 5d9671cb2c
5 changed files with 51 additions and 29 deletions

View file

@ -138,8 +138,8 @@ namespace lib {
* or alternatively resolve these types through a specialisation if IterTraits.
* -# it should be convertible to the pointer type it declares
* -# dereferencing it should yield type that is convertible to the reference type
* - CON refers to the data source of this iterator (typically a data container type)
* We store a backlink to this object to invoke a special iteration control API:
* - CON points to the data source of this iterator (typically a data container type)
* We store a pointer-like backlink to invoke a special iteration control API:
* -# \c hasNext yields true iff the source has yet more result values to yield
* -# \c iterNext advances the POS to the next element
*
@ -150,7 +150,7 @@ namespace lib {
class IterAdapter
: public lib::BoolCheckable<IterAdapter<POS,CON> >
{
const CON* source_;
CON source_;
mutable POS pos_;
public:
@ -158,7 +158,7 @@ namespace lib {
typedef typename IterTraits<POS>::reference reference;
typedef typename IterTraits<POS>::value_type value_type;
IterAdapter (const CON* src, const POS& startpos)
IterAdapter (CON src, POS const& startpos)
: source_(src)
, pos_(startpos)
{

View file

@ -37,7 +37,7 @@ namespace session {
/** TODO??? */
void
QueryResolver::Invocation
QueryResolver::issue (Goal& query)
{
if (!canHandleQuery (query.getQID()))

View file

@ -26,10 +26,12 @@
//#include "proc/mobject/mobject.hpp"
//#include "proc/mobject/placement.hpp"
#include "lib/bool-checkable.hpp"
#include "lib/typed-counter.hpp"
#include "lib/iter-adapter.hpp"
#include "lib/util.hpp"
#include <tr1/memory>
//#include <vector>
//#include <string>
@ -43,8 +45,13 @@ namespace session {
// class Scope;
class Goal;
class QueryResolver;
/** Allow for taking ownership of a result set */
typedef std::tr1::shared_ptr<Goal> PGoal;
/**
* TODO type comment
@ -70,20 +77,30 @@ namespace session {
class Result
: public lib::BoolCheckable<Result>
{
void *cur_;
protected:
void pointAt(void* p) { cur_ = p; }
template<typename RES>
RES& access()
RES&
access()
{
REQUIRE (cur_);
return *reinterpret_cast<RES*> (cur_);
}
public:
bool isValid() const { return bool(cur_); }
Result() : cur_(0) { } ///< create an NIL result
};
static bool hasNext (const Goal* thisQuery, Result& pos) { return unConst(thisQuery)->isValid(pos); } ////TICKET #375
static void iterNext (const Goal* thisQuery, Result& pos) { return unConst(thisQuery)->nextResult(pos);}
static bool hasNext (PGoal thisQuery, Result& pos) { return thisQuery->isValid(pos); } ////TICKET #375
static void iterNext (PGoal thisQuery, Result& pos) { thisQuery->nextResult(pos); }
protected:
QueryID id_;
@ -125,21 +142,25 @@ namespace session {
{ }
/* results retrieval */
class Cursor : public Goal::Result
class Cursor
: public Goal::Result
{
public:
RES& operator* () { return access<RES>(); }
RES* operator->() { return & access<RES>(); }
RES& operator* () { return access<RES>(); }
RES* operator->() { return & access<RES>(); }
void pointAt(RES* r){ Goal::Result::pointAt(r);}
};
typedef lib::IterAdapter<Cursor,Goal> iterator;
operator iterator() ;
typedef lib::IterAdapter<Cursor,PGoal> iterator;
iterator operator() (QueryResolver const& resolver);
};
/**
* TODO type comment
*/
@ -151,15 +172,22 @@ namespace session {
virtual ~QueryResolver() ;
struct Invocation
{
PGoal resultSet;
Goal::Result firstResult;
};
/** issue a query to retrieve contents
* The query is handed over internally to a suitable resolver implementation.
* After returning, results can be obtained from the query by iteration.
* @return Invocation data, containing a smart-pointer which \em owns the result set,
* and the first result or NULL result. Usable for building an IterAdapter.
* @throw lumiera::Error subclass if query evaluation flounders.
* This might be broken logic, invalid input, misconfiguration
* or failure of an external facility used for resolution.
* @note a query may yield no results, in which case the iterator is empty.
*/
void issue (Goal& query);
Invocation issue (Goal& query);
protected:
@ -174,14 +202,7 @@ namespace session {
Query<RES>::operator() (QueryResolver const& resolver)
{
resolver.issue (*this);
return *this;
}
template<typename RES>
Query<RES>::operator iterator()
{
UNIMPLEMENTED ("how to get the result iterator");
return iterator ();
}

View file

@ -82,10 +82,11 @@ namespace test{
/* ==== Exposing Iterator interface(s) for the clients ====== */
typedef IterAdapter<_Vec::iterator, TestContainer> iterator;
typedef IterAdapter<_Vec::const_iterator, TestContainer> const_iterator;
typedef PtrDerefIter<iterator > ref_iterator;
typedef PtrDerefIter<const_iterator> const_ref_iter;
typedef IterAdapter<_Vec::iterator, const TestContainer*> iterator;
typedef IterAdapter<_Vec::const_iterator, const TestContainer*> const_iterator;
typedef PtrDerefIter<iterator > ref_iterator;
typedef PtrDerefIter<const_iterator> const_ref_iter;
iterator begin () { return iterator (this, numberz_.begin()); }

View file

@ -3476,7 +3476,7 @@ Then, running the goal {{{:-resolve(T, stream(T,mpeg)).}}} would search a Track
In the design of the Lumiera Proc Layer done thus far, we provide //no possibility to introduce a new object kind// into the system via plugin interface. The system uses a fixed collection of classes intended to cover all needs (Clip, Effect, Track, Pipe, Label, Automation, ~Macro-Clips). Thus, plugins will only be able to provide new parametrisations of existing classes. This should not be any real limitation, because the whole system is designed to achieve most of its functionality by freely combining rather basic object kinds. As a plus, it plays nicely with any plain-C based plugin interface. For example, we will have C++ adapter classes for the most common sorts of effect plugin (pull system and synchronous frame-by-frame push with buffering) with a thin C adaptation layer for the specific external plugin systems used. Everything beyond this point can be considered &quot;condiguration data&quot; (including the actual plugin implementation to be loaded)
</pre>
</div>
<div title="QueryResolver" modifier="Ichthyostega" modified="200910241336" created="200910210300" tags="Rules spec draft img" changecount="10">
<div title="QueryResolver" modifier="Ichthyostega" modified="200910251518" created="200910210300" tags="Rules spec draft img" changecount="11">
<pre>Within the Lumiera Proc-Layer, there is a general preference for issuing [[queries|Query]] over hard wired configuration (or even mere table based configuration). This leads to the demand of exposing a //possibility to issue queries// &amp;mdash; without actually disclosing much details of the facility implementing this service. For example, for shaping the general session interface (in 10/09), we need a means of exposing a hook to discover HighLevelModel contents, without disclosing how the model is actually organised internally (namely by using an PlacementIndex).
!Analysis of the problem
@ -3496,7 +3496,7 @@ The situation can be decomposed as follows.[&gt;img[QueryResolver|uml/fig137733.
!!!Decisions
* while, in the use case currently at hand, the query instance is created by the client on the stack, the possibility of managing the queries internally is deliberately kept open. Because otherwise, we had to commit to a specific way of obtaining results, for example by assuming always to use an embedded STL iterator.
* we endorse that uttermost performance is less important than clean separation an extensibility. Thus we accept accessing the current position pointer through reference and we package a ref-counting mechanism together with this current position (&quot;Cursor&quot;)
* we endorse that uttermost performance is less important than clean separation an extensibility. Thus we accept accessing the current position pointer through reference and we use a ref-counting mechanism alongside with the handed out iterator
* the result set is not tied to the query &amp;mdash; at least not by design. The query can be discarded while further exploring the result set.
</pre>
</div>