|
Boost : |
From: Matthew Vogt (mvogt_at_[hidden])
Date: 2004-03-01 17:32:43
Mark Blewett <boost <at> blewett.nildram.co.uk> writes:
> >generated by proxy
> >objects which describe interfaces? (Yes, I am quite enamoured of that
> >idea :))
>
> Interesting idea... assuming I'm understanding correctly.. in that the
> callback is created by an object in the servant class, the above becomes;
>
> class MyServant : public Servant
> {
> public:
> MyServant(Scheduler* scheduler) : Servant(scheduler), fn(this,
> &MyServant::do_fn) {}
> MethodProxy<MyServant, int, int> fn;
> private:
> void do_fn(int x, int y) { std::cout << x << " " << y << std::endl; }
> };
>
> int main()
> {
> Scheduler scheduler;
> scheduler.start(1,1);
>
> MyServant my_servant(&scheduler);
> my_servant.fn(1, 2); // certainly a lot easier to understand
> than previous example!
>
> scheduler.stop();
> return 0;
> }
Yes, that's what I was referring to.
Also, I think it should be possible to do the same for values returned from
invoking the methods of another object:
class SomeClass
{
public:
std::string value(int id) { return "foo"; }
}
class SomeServant : public Servant, private SomeClass
{
public:
SomeServant() : getValue(&SomeServant::value, this) {}
MethodProxy<std::string (int)> getValue;
};
class OtherServant : public Servant
{
public:
void findAndStoreValue(SomeServant& other, int id)
{
ReturnProxy<void (std::string)>(&storeValue) = other.getValue(int);
}
private:
void storeValue(std::string value) { ... }
}
(Although that would require some nasty overloading of the meaning of
operator= in the proxy...)
So, the return address of the cross-thread method call can also be encoded,
and the result result delivered by the same mechanism (which is one of the
properties scott was keen on).
Can the template parameter of ReturnProxy be discovered by the compiler?
Anyway, I think some reasonably clean syntax can be found to bind both the
arguments and the return address into the function call, provided that the
return address is a method in the invoking object.
Matt
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk