Boost logo

Boost :

From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2006-04-10 02:56:46


On 4/10/06, Jarl Lindrud <jlindrud_at_[hidden]> 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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk