My Proto review follows.
I'll say straight away that Proto should certainly be accepted. What
it provides is useful, demonstrated by its use in e.g. Spirit; I
suspect that even Eric will be surprised by how many and varied the
future applications for it will be. The key to that wide usage will be
the documentation. That that currently exists is excellent, but more
can only help. Eric, why not write a book?
This review is the result of about 4 hours playing. I think I've only
scratched the surface of what's possible.
My initial prejudice was that I would find incomprehensible error
messages resulting from even the smallest syntax error, making it
impossible for me to deviate far from the examples. And very long
run-times that make the compiler swap. This was based on my experience
with Spirit a few years ago. But I was pleasantly surprised: I'm not
sure if that's me getting better at parsing the long error messages
that you get from heavily-templated code, or whether the compiler or
library had something to do with it. Anyway, I was very pleased with
the amount of progress that I made in the time.
As an example I decided to try to implement the following. Say I have
a multi-threaded application with variables, mutexes and perhaps
condition variables bundled like this:
template <typename T>
struct Locked {
T var;
Mutex mut;
Condition cond; // maybe
};
Locked<int> a;
Locked<bool> b;
I'd like to be able to write something like:
b = (a==3 || a>10);
and for that to lock the mutexes belonging to a and b, evaluate the
expression, and then
unlock the mutexes:
a.mut.lock(); // Or use a multiple-mutex-locking algorithm with back-off
b.mut.lock();
b.var = (a.var==3 || a.var>10);
b.mut.unlock();
a.mut.unlock();
Is that possible with Proto? Yes!
A variation is to be able to write:
wait_until(a==3 || a>10);
That would need to lock a's mutex, evaluate the expression, and if it's
not true wait on the condition variable and retry. (This gets more
complex with more than one variable in the expression as we don't have
a way to wait on any one of a set of condition variables.)
So the first thing that I need to be able to do is to build a set of
all the Locked<> variables in the expression. I need to define an
evaluation context in which Locked<> variables return a singleton set
of themselves, other terminals return an empty set, and non-terminals
return the union of the sets returned by their operands. I'll need to
change my Locked<> class slightly so that I can store a set of pointers
to them:
struct Locked_base {
Mutex mut;
Condtion cond; // optional
};
template <typename T>
struct Locked: public Locked_base {
T var;
};
typedef std::set<Locked_base*> locked_var_set;
I'm not very enthusiastic about using a std::set here, since the set
will presumably actually be constructed and iterated through at
run-time, which has some overhead compared to the code with the
explicit mut.lock() and mut.unlock() calls above. Is there some sort
of fusion-set or other metaprogramming magic that I could use?
Apparently there is and I'll come back to that.
Anyway, for now I'll define an evaluation context that builds a std::set:
struct get_locked_vars_context:
proto::callable_context<get_locked_vars_context const>
{
typedef locked_var_set result_type;
// Return a singleton set for Locked<T>:
template <typename T>
locked_var_set operator()(proto::tag::terminal, const Locked<T>& l)
const {
// It took me a while to work out out what the prototype for this
should be;
// I didn't find anything similar in the examples.
locked_var_set s;
s.insert(&l);
return s;
}
// Return an empty set for other terminals:
template <typename T>
locked_var_set operator()(proto::tag::terminal, const T&) const {
return locked_var_set();
}
// For the operators we need something like this:
template <typename Left, typename Right, typename TagT>
locked_var_set operator()(TagT, const Left& left, const Right& right)
const {
locked_var_set s = proto::eval(left,*this);
locked_var_set r = proto::eval(right,*this);
std::copy(r.begin(),r.end(),std::insert_iterator<locked_var_set>(s,s.end()));
return s;
}
// I'm not sure about the TagT thing up there, but it seems to work.
// Presumably something would also be needed for unary expressions.
};
So I can now write:
get_locked_vars_context ctx;
locked_var_set vs = proto::eval( a==proto::as_expr(3) || b, ctx );
// I failed to find as_expr() in the documentation.
But while I was writing that I realised that I could just store the
locked_var_set in the context and get much simpler code:
struct get_locked_vars_context:
proto::callable_context<get_locked_vars_context>
{
locked_var_set var_set;
typedef void result_type;
template <typename T>
void operator()(proto::tag::terminal, Locked<T>& l) {
var_set.insert(&l);
}
template <typename T>
void operator()(proto::tag::terminal, const T&) {
}
template <typename Left, typename Right, typename TagT>
void operator()(TagT, Left& left, Right& right) {
proto::eval(left,*this);
proto::eval(right,*this);
}
};
and then write:
get_locked_vars_context ctx;
proto::eval( a==proto::as_expr(3) || b, ctx );
locked_var_set vs = ctx.var_set;
Now I need the locking and unlocking, and the actual expression
evaluation (which needs a
different context):
void lock_all(const locked_var_set& vs) {
for (locked_var_set::const_iterator i = vs.begin();
i != vs.end(); ++i) {
(*i)->mut.lock();
}
}
void unlock_all(const locked_var_set& vs) {
for (locked_var_set::const_reverse_iterator i = vs.rbegin();
i != vs.rend(); ++i) {
(*i)->mut.unlock();
}
}
struct eval_context:
proto::callable_context<eval_context const>
{
typedef int result_type;
// ???? The result type for each subexpression will be different, so
I don't want
// to have to define a result_type here. Presumably this is
something that I can
// do if I don't use the callable_context convenience, right? How
should I do that?
// Use the default behaviour for everything, except that for the
Locked<> terminals
// we read the contained variable.
template <typename T>
T operator()(proto::tag::terminal, Locked<T>& l) const {
return l.var;
}
};
// Here's a function that does the locking, evaluation and unlocking:
template <typename ExprT>
int eval_locked_expr(ExprT expr) // same question as above about the
result type
{
get_locked_vars_context glv_ctx;
proto::eval(expr, glv_ctx);
lock_all(glv_ctx.var_set);
eval_context eval_ctx;
int r = proto::eval(expr, eval_ctx);
unlock_all(glv_ctx.var_set);
return r;
}
// It's used like this:
Locked<int> a;
Locked<bool> b;
eval_locked_expr( a==proto::as_expr(3) || b );
So the only thing that's missing is the actual assignment. Proto
doesn't overload operator= because the language only allows it to be
overloaded as a member, not as a binary free function. But I can
overload operator= inside my Lockable<> class. Would it be possible
for me to write:
proto::complicated-expr-type
MyClass::operator=(proto::other-compilcated-type) {
return something...;
}
?
Or maybe MyClass can inherit from proto::something and get definitions
of operator=, operator+= etc. etc. Is that done or do-able?
I've no idea how to start coding that, but instead I can do something a
bit simpler for this case:
template <typename T>
struct Locked: public Locked_base {
T var;
template <typename ExprT>
T operator=(ExprT expr) {
mut.lock();
T r = var = eval_locked_expr(expr);
mut.unlock();
return r;
}
};
Now that can be used as follows:
Locked<int> a;
Locked<bool> b;
Locked<bool> c;
c = ( a==proto::as_expr(3) || b );
(There's a pretty serious flaw with this, which is that if the target
of the assignment also appears in the expression then it will attempt
to lock it twice.)
So the only thing that's needed to "perfect" that is to get rid of the
proto::as_expr() noise, which could be done if the 'a' in 'a==3' were a
proto expression. Can I do that by adding a conversion to
proto::some-complicated-type in Locked<>?
Perfect. Except that it will build and iterate through a std::set at
run time. So, can I instead build and iterate through a compile-time set?
I think that what I need to do is to apply the fold_tree transformation
to the expression to get a fusion container of the Locked<> terminals,
and then to fusion::for_each to do the locking and the unlocking.
Having never used fusion I'm not going to try that now - it's getting
late, and it's not going to change my vote! - but if someone would like
to work it out for me I'd love to see how to do it.
Review questions:
- What is your evaluation of the design?
Looks good. It would be great if it could all be simpler, but I doubt
that's possible.
- What is your evaluation of the implementation?
I haven't looked inside the source files. I have not encountered any
warnings or errors, which is a good sign.
- What is your evaluation of the documentation?
Good. But the complexity of the subject means that the quality of the
documentation will be critical to the widespread uptake of the library.
- What is your evaluation of the potential usefulness of the library?
Considerable.
- Did you try to use the library? With what compiler? Did you have
any problems?
Yes, with g++ 4.1.3 on Linux. No problems.
- How much effort did you put into your evaluation? A glance? A quick
reading? In-depth study?
About 4 hours.
- Are you knowledgeable about the problem domain?
Not especially.
Regards, Phil.
