On 4/10/06, Jarl Lindrud <jlindrud@hotmail.com> wrote:
Felipe Magno de Almeida <felipe.m.almeida <at> gmail.com> writes:
Looks very interesting, but why the macros are needed?
The macros generate C++ class definitions, with user-specified member functions. You can't do that with templates. The use of macros, in this case, results in lot less boilerplate code for the user to write.
Wouldnt this be possible? std::string foo(std::string); rcf::server s(endpoint); rcf::binder<std::string(std::string)> echo(&foo); int main() { s.register("IEcho", echo); server.run(); // blocks return; } If binder deserialize I believe it could call echo. Or am I missing something? Probably so, since BIL uses macros the same way as RCF.
Sorry if I missed the explanation in the url, I went very fast in it. Are you aware of Boost.Interfaces (not submitted to boost for review yet, I think). Google pointed this URL for boost.interfaces: http://www.cdiggins.com/bil.html
I've had a look at it, and it builds on the same idea (static interfaces) that RCF does. It's much more general, though. In RCF, the static interfaces are focused on implementing IPC's.
Yes, what I wanted to say(but forgot to) is that RCF could use it. As it could use shmem and asio for IPC. That would make rcf with a cleaner interface. BTW, I dont like very much the RCF namespace all in caps, it seems like a macro. But that's just an aesthetic issue.
The BIL library uses macros too, BTW, for the same purpose that RCF uses them.
Yes.
I know there's a lot of skepticism towards macros in general, but in this setting, the alternative is a 3rd party code generator, or do-it-by-hand boilerplate coding.
Yes, I agree. I just wanted some sort of rationale about why macros and what other alternatives are and why they are inferior.
Jarl.
Thanks, very good library! -- Felipe Magno de Almeida