Boost logo

Boost :

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-06-30 10:05:43

"Joel de Guzman" <joel_at_[hidden]> wrote

> I like the idea behind the Interfaces Library:
> I need one now. I dislike the macro-based Interface
> Definition Language, however. I find it utterly ugly
> especially because interfaces should be immediately
> readable. IMO, the macro-based IDL is not.

"Ugly macros", here we go again ;-)

> Here's another take (prototype) at a macro less
> implementation of the interfaces (see attached).
> Tested on VC7.1, g++ and Comeau. The biggest advantage
> is that the same C++ member function interface syntax
> is retained. This makes it very easy to understand and
> even allows documentation extraction tools like Doxygen
> to work as usual. A disadvantage is that there is some
> unavoidable redundancy-- a lesser price to pay, IMO.

So why a solution that clearly involves repeating things multiple times
is less ugly than a macro-based approach, that allows to avoid duplication?

> Here's a client side example:
> struct foo : member_function<int(int)> {};
> struct bar : member_function<int(char const*)> {};
> // a baz "interface"
> class baz : interface<foo, bar>
> {
> public:
> template <class T>
> baz(T& x) : construct(x) {}
> int foo(int x)
> { return this->call< ::foo>(x); }

And, in a little bit more involved case:

int foo(int x, string y, double z, char* psz1, char* psz2)
{ return this->call< ::foo>(x, y, z, psz2, psz1); } // Oops, unintended

> ...

IMHO, the fact that interfaces are currently built with code generators
speaks for using yet another code generator, which is a macro mechanism.
even though I havn't really looked at the Interfaces Library close enough, I
support the general idea of using macros for interfaces.


Boost list run by bdawes at, gregod at, cpdaniel at, john at